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TCP/IP PARA PENTESTERS 
Por Ricardo Longatto | Desec Security 
INTRODUÇÃO A REDES DE COMPUTADORES 
Uma rede de computador é a comunicação entre dois ou mais computadores capazes 
de trocar informações entre si. 


Cada computador na rede pode ser chamado de Host e em uma rede podemos ter 
os hosts cliente e servidor. 


O servidor é um host que fornece algum serviço a rede e o cliente é um host que 
consome algum serviço oferecido por um servidor. 


Exemplos de servidores: 


Servidor Web (www) — Fornece um recurso web (site, aplicação, etc.) 
Servidor de Arquivos — Armazena arquivos dos hosts clientes 


Vamos imaginar que na nossa rede teremos um site, para isso, precisamos de um 


servidor web. Esse host servidor web vai fornecer o site a todos os hosts nessa rede, 
esses hosts serão as máquinas clientes. 


AAA 
——— — 


Cliente Servidor (WEB) 


Acontece que existem centenas de hardware e softwares diferentes, podemos ter 
computadores Intel, AMD, Dell, Apple assim como sistemas operacionais diferentes 
como Windows, Linux, FreeBSD, macOS etc. 


Como que esses computadores podem trocar informações entre si já que são tão 
diferentes? 


É aí que entra os Protocolos 


Os protocolos garantem que diferentes computadores usando diferentes hardwares 
e softwares consigam se comunicar. 


Exemplo de protocolo de rede: TCP/IP 
No nosso exemplo o computador cliente é um Macbook da Apple rodando o sistema 


operacional macOS e está se comunicando com um servidor Web em um Dell 
rodando o sistema operacional Linux. 
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5 WWW 
= inu 
Mac a = + 
Å — 
Cliente Servidor (WEB) 


Essa comunicação só ocorre pois existe um protocolo, no qual, ambos os lados 
compreendem. 


Para que a comunicação ocorra precisamos dos endereços físicos, lógicos e 
portas. 


O endereço físico é conhecido como MAC Address e vem definido de fábrica. 


O endereço lógico é atribuído ao adaptador de rede de acordo com a configuração 
da rede, o endereço lógico é conhecido como endereço IP. 


De forma simplificada as portas são utilizadas para interligar máquinas clientes e 
servidores durante uma comunicação com um serviço. 


| 
Mac al à. 
 — 


Cliente Servidor (WEB) 
Endereço MAC: a4:5e:60:b8:cl:af (placa de rede) Endereço MAC: 00:0C:29:76:43:El (placa de rede) 
Endereço IP: 192.168.0102 Endereço IP: 192. 168.0.200 
Porta: 50234 Porta: 80 


Conforme podemos ver na imagem acima, a máquina cliente tem um endereço físico 
(Mac Address) a4:5e:60:b8:c1:af e endereço lógico (IP Address) 192.168.0.102 e 
porta 50234. 


E no servidor tem um endereço físico (Mac Address) 00:0c:29:76:43:e1 e endereço 
lógico (IP Address) 192.168.0.200 e porta 80. 


Vamos ver alguns detalhes 

Endereço Físico (Mac Address) 

O Mac Address é formado por uma sequência de 6 bytes onde os 3 primeiros bytes 
definem quem é o fabricante e os últimos 3 bytes é uma sequência única gerada pelo 
fabricante. 


Exemplo: 


A4:5E:60:B8:C1:AF 


Fabricante Seq. única 
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Podemos descobrir o fabricante pesquisando na oui.txt ou em sites que automatizam 


O processo. 


http://standards-oui.ieee.org/oui/oui.txt 
https://macvendors.com/ 


C 0 “O Not Secure | standards-oui.ieee.org/oui/oui.txt 


Cupertino CA 95014 
us 


FO-DB-E2 (hex) Apple, Inc. 

FODBE2 (base 16) Apple, Inc. 
1 Infinite Loop 
Cupertino CA 95014 
us 


74-81-14 (hex) Apple, Inc. 

748114 (base 16) Apple, Inc. 
1 Infinite Loop 
Cupertino CA 95014 
us 


18-F6-43 (hex) Apple, Inc. 

18F643 (base 16) Apple, Inc. 
1 Infinite Loop 
Cupertino CA 95014 
us 


A4-5E-60 (hex) Apple, Inc. 

45260 (base 16) Apple, Inc. 
1 Infinite Loop 
Cupertino CA 95014 
us 


CO fi https://macvendors.com 


MA:CV:en:do:rs 


Find MAC Address Vendors. 


Enter a MAC Address 


A4:5E:60 


Apple, Inc. 


Ambos os casos nos retornam Apple confirmando que o hardware do host cliente se 
trata de um macbook. 


Por mais que o Mac Address tem um endereço único de fábrica é possível alterar o Mac 
Address facilmente. 


Do ponto de vista de segurança podemos trocar nosso Mac Address verdadeiro para dificultar 
a identificação via mac address, também podemos fazer o que chamamos de mac spoofing 


que é trocar nosso mac address por um que é liberado na rede permitindo assim burlar 
controles baseado em mac address. 


No Linux podemos ver nosso endereço mac através do comando ifconfig 


Para alterar o endereço mac no Linux podemos utilizar o macchanger (-r para um 
novo mac aleatório) 
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:-% ifconfig etho 
etho: flags=4163<UP, BROADCAST, RUNNING, MULTICAST> mtu 1500 
inet 192.168.0.200 netmask 255.255.255.0 broadcast 192.168.0.255 
inet6 fe80::20c:29ff:fe76:43el prefixlen 64 scopeid 0x20<link> 
inet6 2804:14d:7841:828a:20c:29ff:fe76:43e1 prefixlen 64 scopeid 
txqueuelen 1000 (Ethernet) 
RX packets 119010 bytes 50912160 (48.5 MiB) 
RX errors © dropped © overruns O frame 0 
TX packets 4028 bytes 503737 (491.9 KiB) 
TX errors © dropped O overruns © carrier © collisions 0 


erminal 


¿$ macchanger -r etho 
Current MAC: 00:0c:29:76: el (VMware, Inc.) 
MAC: 00:0C:29:76: el (VMware, Inc.) 
ee:c2:c0:03: 7e (unknown) 


Endereço Lógico (Endereço IP) 


O endereço IP é formado por quatro octetos representados de forma decimal 
separados por ponto. 


Por exemplo: 
192.168.0.102 


A atribuição do endereço IP pode ocorrer de forma estática (o usuário configura o IP) 
ou de forma dinâmica onde a máquina recebe um endereço IP automaticamente 
(DHCP). 


Existem várias classificações de endereço IP e cada uma serve para definir o uso em 
uma rede de acordo com a necessidade e quantidade de hosts. 


Também existe o que chamamos de máscara de rede que serve para segmentar a 
rede. 


Exemplo: 


255.255.255.0 
R R RH 


R = Rede 
H = Host 


Nesse caso onde temos o IP 192.168.0.102 com máscara de rede 255.255.255.0 
portanto estamos definindo qual parte é rede e qual parte é host. 


192.168.0.102 
l Ed 

Rede Host 
192.168.0.200 


L 
Rede Host 
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O IP vai de 0 a 255 sendo assim na rede 192.168.0 podemos ter até 254 hosts, se 
utilizarmos outra máscara de rede (255.255.0.0) podemos aumentar a quantidade de 
hosts. 


Outra informação importante é que esse IP 192.168.0.102 é um IP de uso para rede 
interna, ele não é acessível diretamente pela internet. 


O IP Público é o endereço IP acessível pela internet 
Exemplos: 


177.154.144.104 
200.103.45.198 


€ C ñ à https://www.google.com 


Google  myip sa 


QAI Œ Maps (New Ç] Videos < Shopping E More Settings Tools 


About 1,120,000,000 results (0.72 seconds 


199.229.249.178 


Your public IP address 


Roteamento 


Redes diferentes só se enxergam através do roteamento de rede, para isso precisam 
definir um gateway. 


$ W < + 
WWW 
Mac Roteador: 192.168.0.1 A 


Cliente Servidor (WEB) 
Endereço IP: 192.168.0.102 Endereço IP: 200.123.123 
Gateway: 192.168.0.1 


No exemplo acima o gateway é o endereco IP do roteador wifi do cliente que está 
acessando o servidor web na internet através de um IP público. 


O pacote só consegue sair da rede 192.168.0. e chegar ao IP público graças ao 
gateway que faz o roteamento. 


Portas 


De forma simplificada as portas são utilizadas para interligar máquinas clientes e 
servidores durante uma comunicação com um serviço. 
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Geralmente nos servidores temos números de portas fixas de acordo com cada 
serviço e no lado do cliente números de portas aleatórios. 


Por exemplo: 


Um servidor WEB (www) por padrão usa a porta 80, assim como um servidor FTP 
usa a porta 21 e um servidor SSH usa a porta 22 por padrão e assim por diante. 


É possível consultar essa lista de portas e serviços padrão no próprio Linux através 
do arquivo /etc/services 


GNU nano 4.3 /etc/services 
20/tcp 
21/tcp 
21/udp fspd 
22/tcp SSH Remote Login Protocol 
23/tcp 
25/tcp mail 
37/tcp timserver 
37/udp timserver 
39/udp resource resource location 
42/tcp name IEN 116 
43/tcp nicname 
49/tcp Login Host Protocol (TACACS) 
49/udp 
53/tcp Domain Name Server 
53/udp 
67/udp 
68/udp 
69/udp 
70/tcp # Internet Gopher 
79/tcp 
80/tcp WWW & WorldWideweb HTTP 
87/tcp ttylink 
88/tcp kerberos5 krb5 kerberos-sec & Kerberos v5 
88/udp kerberos5 krb5 kerberos-sec # Kerberos v5 
102/tcp tsap # part of ISODE 
104/tcp dicom # Digital Imag. & Comm. 300 
110/tcp pop-3 # POP version 3 
111/tcp portmapper # RPC 4.0 portmapper 
111/udp portmapper 


Isso não significa que seja obrigatório o serviço ser executado na porta padrão, é 
possível mudar a porta padrão por qualquer outra porta que não esteja em uso. 


Por exemplo: 


O servidor SSH pode ser configurado para funcionar na porta 22222 ao invés da porta 
22 


As portas vão de O a 65535 e normalmente são usadas com o protocolo TCP e UDP 


Do lado do cliente a porta que origina o acesso geralmente é uma porta alta (acima 
de 1024) e definida de forma aleatória. 
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Linux A 
—_ 
Cliente Servidor (WEB) 
Endereço MAC: a4:5e:60:b8:cl:af (placa de rede) Endereco MAC: 00:0C:29:76:43:El (placa de rede) 
Endereço IP: 192.168.0102 Endereço IP: 192168.0.200 


Porta: 50234 Porta: 80 


No nosso exemplo a porta de origem é 50234 (aleatória no momento da conexão) já 
a porta de destino é 80 (fixa para o servidor WEB) 


Socket 


Podemos dizer que o socket para se conectar a esse servidor é 192.168.0.200:80 
(IP:Porta) que é formado pelo conjunto de IP e Porta. 


Conclusão 


Na nossa rede temos 2 computadores com diferentes hardwares e softwares se 
comunicando através de uma rede de computadores, a comunicação entre eles só é 
possível pois ambos compreendem o mesmo protocolo de comunicação (TCP/IP) 


Um dos hosts é o cliente (Macbook) e o outro é o servidor (Dell) no qual fornece o 
serviço de web, cada host tem um endereço físico conhecido como Mac Address, um 
endereço lógico conhecido como endereço IP e portas. 


Se a comunicação for entre redes diferentes é necessário um roteamento para que 
as diferentes redes possam se comunicar. Nesse caso é necessário saber o endereço 
do gateway. 
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ENTENDENDO OS PROTOCOLOS DE REDE 


A maioria dos protocolos de rede possuem uma estrutura que podemos dividir em 
duas partes: 


Header (cabeçalho) — Contém as informações de tráfego e controle do protocolo e 
cada header tem uma estrutura específica. 


Payload (área de dados) — Contém as informações que o protocolo carrega 


Header 


Payload 


Antes de nos aprofundarmos nos protocolos vamos falar brevemente sobre os 
modelos de referência. 


Modelos de Referância 


Anteriormente você viu que a comunicação de rede entre máquinas com diferentes 
hardwares e softwares só é possível por conta da existência de protocolos. 


Essa padronização ocorreu justamente para serem utilizados como uma referência 
aos desenvolvedores de software e fabricantes de hardware, afim de criar produtos 
compatíveis entre si. 


O Modelo OSI (Open Systems Interconnection) é um modelo conceitual composto de 
7 camadas. 


O Modelo TCP/IP é composto por 4 camadas e tornou-se uma simplificação do 
modelo OSI. 


OSI TCP/IP 
Aplicação 
Apresentação Aplicação 


Sessão 


Transporte Transporte 


Enlace Acesso a Rede 


Física 


Basicamente cada camada tem sua funcáo e cada protocolo atua em uma camada 
específica, mais a frente iremos compreender isso de forma prática. 
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Antes de continuar acho importante mencionar que além das referências oficiais 


como o modelo OSI ou modelo TCP/IP, é possível encontrar algumas divisões não 
oficiais que podemos chamar de modelo híbrido onde a divisão ocorre em 5 
camadas. 


Aplicação 


Não oficial 


Vamos voltar ao nosso exemplo para conseguirmos compreender a fundo como a 
comunicação de rede funciona. 


No nosso exemplo temos 2 hosts (cliente e servidor) onde o cliente vai acessar o 
servidor web na rede interna. 


Para que essa comunicação ocorra teremos vários protocolos envolvidos. (Ethernet, 
ARP, IP, TCP, HTTP). 


Cada protocolo atuando em uma camada específica. 


(e EA 
e} į 
Linux A 


Servidor (WEB) 


Ao abrir o navegador e digitar o IP do servidor podemos visualizar o conteúdo do 
servidor web. 


ú Chrome File Edit View History Bookmarks People Window Help 


É 192.168.0.200 x + 


C À O Not Secure | 192.168.0.200 


BEM VINDO AO SERVIDOR DESEC SECURITY 
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Acontece que nos bastidores muita coisa aconteceu para que essa simples ação 


pudesse ser realizada. Vamos entender como tudo ocorre nos bastidores. 


A partir de agora você vai descobrir um mundo de informação e entender a fundo o 
que acontece entre uma simples comunicação entre um cliente e servidor. 


Para iniciar vamos entender um pouco sobre cada protocolo envolvido, começando 
pelo protocolo Ethernet. 


TEORIA DOS PROTOCOLOS 
PROTOCOLO ETHERNET 


O protocolo ethernet atua na camada 2 do modelo OSI e é responsável por 
encapsular o protocolo IP em redes locais. 


Encapsular na prática significa que o payload (área de dados) do ethernet pode 
armazenar outros protocolos como por exemplo o protocolo IP. 


O protocolo ethernet conhece apenas endereços físicos (Mac Address) 
A estrutura de um frame ethernet é a seguinte: 


Mac de destino | Mac de Origem Tipo - Checksum 


Antes do frame ethernet ainda temos o préambulo que é um conjunto de bytes que 
avisa sobre a chegada do frame. Mas vamos nos concentrar na parte que importa. 


= Mac de destino — contém o endereço mac da placa de rede de destino 
= Mac de origem — contém o endereço mac da placa de rede de origem 


= Tipo- contém o código que identifica o tipo de protocolo que estará no payload, 
sendo 0800 para protocolo IP e 0806 para o protocolo ARP. 


= Payload — contém os dados a serem transportados (outro protocolo), o 
tamanho máximo do payload ethernet é de 1500 bytes 
= Checksum — Faz a verificação de erros 


Na imagem a seguir podemos ver toda essa estrutura confirmada em um frame 
ethernet real. 


Ethernet II, Src: Vmware 76:43:e1 (00:0Cc:29:76:43:e1), Dst: Broadcast (ff:ff:ff:ff:ff:ff) 


+ Destination: Broadcast (ff:ff:ff:ff:ff:ff) 
+ Source: Vmware 76:43:e1 (00:0Cc:29:76:43:e1) 
Type: ARP (0x0806) 
+ Address Resolution Protocol (request) 


Destino temos o broadcast (endereço que indica todo segmento ethernet) 
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Origem temos 00:0c:29:76:43:e1 
No tipo temos o código 0806 que indica que o protocolo ARP estará no payload 
E abaixo o Type temos o payload com o protocolo ARP 


ENTENDENDO O PROTOCOLO ARP 
O ARP tem a habilidade de descobrir qual endereço MAC está associado a 
determinado endereço IP, isso é importante pois antes de enviarmos algo para um 
determinado host que sabemos o IP precisamos saber o seu endereço MAC. 


E ai que entra o protocolo ARP e o famoso ARP Request e ARP Reply. 


ARP Request serve para fazer uma requisição para todo segmento ethernet 
perguntando quem tem um determinado IP e qual o seu MAC. 


Todo segmento ethernet é representado por ff:ff:ff:ff:ff:ff, com isso todos os hosts 
naquele segmento vão receber o ARP Request. 


ARP Reply é a resposta enviada pela máquina que tem o IP requisitado pelo ARP 
Request, nessa resposta a máquina que possui as informações envia o seu Mac 
Address. 


O host que recebe a resposta (ARP Reply) armazena na memória por um tempo o 
IP e MAC, dessa forma não precisa reutilizar o protocolo ARP pois já conhece o IP e 
MAC. 


No Linux podemos ver a tabela arp com o comando arp -an 


:-% arp -an 
? (192.168.0.1) at d4:ab:82:45:c4:0c [ether] on etho 


A 


A tabela acima mostra apenas o endereco MAC do roteador, mas por exemplo, se 
alguma outra máquina da rede local tentar acessar esse servidor (web), a nossa 
tabela arp será atualizada “automagicamente”. 


:~# arp -an 
? (192.168.0.11) at a4:5e:60:b8:d1:af [ether] on etho 


? (192.168.0.1) at d4:ab:82:45:c4:0c [ether] on etho 


Ok, isso não foi mágica, como eu disse anteriormente para que os computadores 
possam se comunicar na rede local precisamos saber o endereço MAC, quando 
chega um acesso de outro IP (192.168.0.11) no servidor e ele precisa responder a 
essa comunicação então o servidor dispara um ARP Request para descobrir o MAC 
desse host, quando ele recebe o reply ele atualiza a tabela arp conforme mostrado 
acima. 
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ESTRUTURA DO PROTOCOLO ARP 


Target protocol address (IP 


Vamos entender isso na prática, na imagem abaixo podemos ver um frame ethernet 
com protocolo ARP encapsulado. 


Ethernet II, Src: Viware_76:43:e1 (66:00:29:76:43:e1), Dst: Broadcast (FFIFFIFFIFFIFFIFF) 
~ Address Resolution Protocol (request) 
Hardware type: Ethernet (1) 
Protocol type: IPv4 (0x0800) 
Hardware size: 6 
Protocol size: 4 
Opcode: request (1) 
Sender MAC address: Vmware 76:43:e1 (00:0Cc:29:76:43:e1) 
Sender IP address: 192.168.0.200 
Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00) 
Target IP address: 192.168.0.11 


Podemos notar que o frame ethernet tem o destino broadcast (todo o segmento) e no 
payload dele temos o protocolo ARP. 


No protocolo ARP temos toda estrutura do protocol ARP montada na prática. 


Hardware Type — é o tipo de hardware usado, no caso, o tipo 1 que é para redes 
Ethernet. 


Protcolol type — Temos IPv4 através do valor 0x0800. 

Hardware size — temos o tamanho do hardware (6 bytes referente ao mac) 

Protocol size — temos o tamanho do protocol (4 bytes) 

Opcode — temos o tipo da operação onde 1 é arp request e 2 arp reply. 

Sender Mac Address — temos o mac da origem, de quem está enviando 

Sender IP address — temos o IP da origem, de quem está enviando 

Target MAC Address — é o MAC que queremos saber, quando não sabemos será 
zerado. 

Target IP Address — temos o IP do destino. 


Resumindo — Arp Request 


Frame ethernet será enviado para broadcast (todo segmento) e terá em seu payload 
o protocolo ARP. 
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O protocolo ARP terá seu opcode como 1 indicando ser o Arp Request e terá o Target 
Mac Address zerado pois é a informação que o request quer descobrir. 


Agora vamos ver o ARP Reply 


Ethernet II, Src: Apple b8:d1:af (a4:5e:60:b8:d1:af), Dst: Vmware 76:43:e1 (00:0c:29:76:43:e1) 


~ Address Resolution Protocol (reply) 
Hardware type: Ethernet (1) 
Protocol type: IPv4 (0x0800) 
Hardware size: 6 
Protocol size: 4 
Opcode: reply (2) 
Sender MAC address: Apple_b8:d1:af (a4:5e:60:b8:d1:af) 
Sender IP address: 192.168.0.11 
Target MAC address: Vmware 76:43:e1 (00:0C:29:76:43:e1) 
Target IP address: 192.168.0.200 


Como diferenca podemos notar que no frame ethernet a origem é o mac address da 
estacáo cliente. 


As diferenças no protocolo ARP são opcode com código 2 indicando ser do tipo reply. 


O Sender Mac Address é o MAC do cliente 
O Sender IP Address é o IP do cliente 

O Target MAC é o Mac do servidor 

O Target IP é o IP do servidor 


Quando esse ARP Reply chega em nosso servidor o servidor (192.168.0.200) agora 
sabe qual é o MAC Address do IP cliente (192.168.0.11) e nesse momento ele 
atualiza a tabela arp em memória. 


:-f arp -an 
? (192.168.0.11) at a4:5e:60:b8:d1:af [ether] on etho 


? (192.168.0.1) at d4:ab:82:45:c4:0c [ether] on etho 


A partir desse momento ambas partes conseguem continuar com a comunicação. 
Conclusão 


O protocolo ARP é muito importante para que a comunicação na rede interna 
ocorra. 


Falei bastante em rede interna, mas você pode pensar..., mas e quando eu 
comunico com a internet, vou ver o MAC do host da internet na minha tabela arp? 


Não, isso porque quem encaminha os pacotes para internet é o roteador então vai 
ser comum você ver o MAC do roteador na tabela arp pois o host se comunica com 
o roteador, e se você analisar os pacotes você vai ver que no frame ethernet o mac 
address será o endereço físico do roteador, nós veremos isso mais a frente. 


Do ponto de vista do pentester conhecer o ARP é importante, por exemplo, em uma 
rede onde você quer descobrir quais hosts estão ativos, e supondo que o ICMP 
(ping) esteja bloqueado, nós podemos enviar um ARP Request para a máquina alvo 
que normalmente ela vai responder com o ARP reply, dessa forma mesmo com o 
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protocolo ICMP bloqueado nós conseguiremos indentificar os hosts ativos por meio 
do protocolo ARP. ;) 


Outro exemplo seria o ataque de arp spoofing, onde a gente pode forjar a resposta 
do arp reply dizendo que o MAC address da máquina alvo é o nosso, dessa forma 
nós conseguimos ficar no meio da comunicação e manipular essa comunicação. 


PROTOCOLO IP 


O protocolo IP é responsável por realizar a entrega de pacotes entre máquinas, por 
padrão ele não é confiável, ele apenas tenta entregar o pacote sem realizar nenhum 
tipo de verificação após a entrega. 


Se quisermos confiabilidade e um controle maior podemos associar o protocolo IP ao 
protocolo TCP e se quisermos velocidade podemos associar o protocolo IP com o 
protocolo UDP, veremos isso um pouco mais a frente. 


Vamos conferir como é formada a estrutura do header do protocolo IP 


Header IP - RFC791 


H-+-+-H-+-+-+-+-H-+-+-+-+--+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+- 

|Version| IHL |Type of Service| Total Length 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Identification [Flags | Fragment Offset 


| 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Time to Live | Proirocoll | Header Checksum 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Source Address 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Destination Address 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Options l Padding 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


Vamos ver isso na prática ainda usando nosso exemplo inicial 


+ Ethernet II, Src: Apple_b8:d1:af (a4:5e:60:b8:d1:af), Dst: Vmware_76:43:e1 (00:0Cc:29:76:43:e1) 
Internet Protocol Version 4, Srce: 192.168.90.11, Dst: 192.168.0.200 


0100 .... = Version: 4 


. 0101 = Header Length: 20 bytes (5) 
Differentiated Services Field: 0x00 (DSCP: CSO, ECN: Not-ECT) 
Total Length: 64 
Identification: 0x0000 (0) 

Flags: 0x4000, Don't fragment 

Time to live: 64 

Protocol: TCP (6) 

Header checksum: 0xb894 [validation disabled] 
[Header checksum status: Unverified] 

Source: 192.168.0.11 

Destination: 192.168.0.200 


» Transmission Control Protocol, Src Port: 56104, Dst Port: 80, Seq: 0, Len: 0 — 


X 


- 


Como podemos ver acima, temos o frame ethernet com origem do host cliente e 
destino host servidor. (sabemos disso olhando o Mac Address conforme visto 
anteriormente) 
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Em seguida temos o Internet Protocol Version 4 (Protocolo IPv4), podemos notar que 
a origem temos o endereço IP do host cliente e no destino o endereço IP do host 
servidor. 


Logo em seguida temos a estrutura do header completa, vamos entende-la 
Version — indica a versão do protocolo, no nosso caso 4 (IPv4) 
IHL — temos o tamanho do header (20 bytes) 


Type of Service ou DSF — define características afim de melhorar a qualidade do 
serviço, na prática não é muito usado conforme podemos ver está zerado 0x00. 


Total length — contém o tamanho total do pacote IP (header + payload) nesse caso 
64 bytes. 


O tamanho máximo de um pacote IP é de 65535 bytes, mas numa rede ethernet se 
o pacote tiver mais de 1500 bytes serão usados vários pacotes. (fragmentação) 


Identification — esse campo é responsável pela fragmentação e identificação do 
pacote IP, no caso do exemplo acima o pacote não precisou ser fragmentado então 
esse campo é 0. 


Flags — quando ocorre a fragmentação as flags ajudam no controle do fluxo de 
fragmentos IP. Aqui podemos encontrar None, DF, MF. 
- None — sempre será O (não é utilizado) 
- DF — Don't Fragment onde O pode fragmentar e 1 não pode fragmentar. 
- MF — More Fragment onde 0 não tem mais fragmentos e 1 tem mais 
fragmentos. 


No exemplo acima a flag setada é DF (Don't Fragment) e tem indicação de não 
fragmentar o pacote sendo assim também podemos ver que não existem mais partes. 
Vamos entender isso a fundo mais a frente. 


Time to live — temos o tempo de vida do pacote, a cada roteador que o pacote passa 
ele decrementa 1, no nosso exemplo temos o valor 64, cada sistema operacional 
usa um tamanho de TTL padrão. 

Exemplos: Linux usa TTL de 64, Windows usa TTL de 128. 


Protocol — Contém o protocolo que será encontrado no payload IP, no exemplo 
acima, tipo 6 = TCP. 


No arquivo /etc/protocols podemos ver a lista de protocolos e seus respectivos 
códigos. Por exemplo: 


1 — ICMP 
6 — TCP 
17 — UDP 
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Header checksum — faz uma verificação para garantir que o header IP esteja 
integro. 
Source Address — Temos o IP de origem (host cliente) 
Destination Address — Temos o IP de destino (host servidor) 
Campo Options — não é obrigatório então nem aparece no nosso exemplo prático 
mas ele poderia conter dados sobre roteadores de passagem obrigatória ou 


roteadores proíbidos etc. 


No payload do protocolo IP temos outro protocolo, no exemplo prático temos o 
protocolo TCP. 


Entendendo a Fragmentação de pacotes 


Um frame ethernet aceita por padrão no máximo 1500 bytes, sendo assim, se o 
pacote IP tiver mais de 1500 bytes ele deverá ser quebrado em diversos pedaços, o 
que chamamos de fragmentação de pacotes. 


Vamos entender isso na prática, dessa forma será possível compreender não só 
como a fragmentação funciona, mas também os campos identification, flags e 
fragment offset. 


Exemplo: O nosso host cliente envia um ping para o host servidor, no entanto, o host 
cliente enviou um pacote com 4000 bytes de tamanho. 


isecbook:- ricardolongatto$ ping -c 1 -s 4000 192.168.0.200 


PING 192.168.0.200 (192.168.0.200): 4000 data bytes 


Não se preocupe em entender o ping agora, nós iremos falar dele mais a frente, no 
momento se atente apenas ao fato do host cliente ter enviado 4000 bytes ao servidor. 


Vamos entender o que aconteceu na rede, como falamos acima o payload ethernet 
aceita no máximo 1500 bytes, como o nosso pacote teve 4000 bytes ocorreu a 
fragmentação. 


A imagem abaixo mostra 3 pacotes (indicação 01) chegando no servidor com origem 
do cliente (192.168.0.11) 
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No. Time Source Destination Protocol Length Info 
1 0.000000 192.168.0.11 192.168.0.200 IPv4 1514 Fragmented IP protocol (proto=ICMP 1, off=0, ID=basa) [R 
01 2 0.001895 192.168.0.11 192.168.0.200 IPv4 1514 Fragmented IP protocol (proto=ICMP 1, off=1480, ID=ba5a) 
. 3 0.001906 192.168.0.11 192.168.0.200 ICMP 1082 Echo (ping) request id-oxfc2b, seq=0/0, ttl=64 (reply il 


+ Ethernet II, Src: Apple_b8:d1:af (a4:5e:60:b8:d1:af), Dst: Vmware 76:43:e1 (00:0c:29:76:43:€e1) 
~ Internet Protocol Version 4, Src: 192.168.0.11, Dst: 192.168.0.200 
0100 .... = Version: 4 
.... 0101 = Header Length: 20 bytes (5) ———————— 02 
+ Differentiated Services Field: 0x00 (DSCP: CSO, ECN: Not-ECT) 
Total Length: 1500 
Identification: Oxbasa (47706) «—————— 04 
- Flags: 0x2000, More fragments 
Birna odio O = Reserved bit: Not set 
Bo. ooo .... = Don't fragment: Not set 
do ico ccoo .... = More fragments: Set <> 05 
...0 0000 0000 0000 = Fragment offset: 0 4———————— 06 
Time to live: 64 
Protocol: ICMP (1) 
Header checksum: 0x18a3 [validation disabled] 
[Header checksum status: Unverified] 
Source: 192.168.0.11 
Destination: 192.168.0.200 


Reassembled IPv4 in frame: 3 07 
4 
+ Data (1480 bytes) 


Vamos ver as informações do primeiro pacote 
Na seta de indicação 02 podemos ver o tamanho do Header IP com 20 bytes. 


Na seta de indicação 03 podemos ver o tamanho do pacote IP com 1500 bytes, 
tamanho máximo aceito em redes ethernet normais. 


Na seta de indicação 04 podemos ver o identification com valor 47706 gerado 
aleatoriamente, isso é importante para podemos identificar as partes dos pacotes 
fragmentados, pois todas elas terão essa identificação. 


Na seta de indicação 05 temos a flag MF habilitada, o que indica more fragments, ou 
seja, existem mais fragmentos desse pacote. 


Na seta de indicação 06 temos o Fragment Offset com valor 0, isso indica que essa 
é a primeira parte do pacote fragmentado. 


Na seta de indicação 07 temos os dados com tamanho de 1480 bytes, isso porque o 
header IP tem 20 bytes, ou seja, o pacote IP completo tem 1500 bytes (1480 bytes 
de dados e 20 bytes de Header IP) 


Vamos ver o segundo pacote (segunda parte do fragmento) e destacar as partes mais 
importantes. 


Av. Presidente Juscelino Kubitschek, 1455 - 4º Andar - São Paulo / SP - (11) 2124-3725 


DESEC SECURITY SEGURANÇA DA INFORMAÇÃO LTDA 


+ Ethernet II, Src: Apple b8:di:af (a4:5e:60:b8:d1:af), Dst: Vmware 76:43:e1 (00:0c:29:76:43:e1) 
+ Internet Protocol Version 4, Src: 192.168.8.11, Dst: 192.168.6.268 

0100 .... = Version: 4 

. 0101 = Header Length: 20 bytes (5) 
+ Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) 
Total Length: 1500 -4-———_——— 01 
Identification: Oxba5a (47706) 4 02 
Flags: 0x20b9, More fragments 
Bisa ara desi aasi = Reserved bit: Not set 

Lorena acc ca.. = Don't fragment: Not set 
Il... 2... .... = More fragments: Set <—————— 03 
-..O 0000 1011 1001 = Fragment offset: 185 

Time to live: 64 

Protocol: ICMP (1) 

Header checksum: 0x17ea [validation disabled] 

[Header checksum status: Unverified] 

Source: 192.168.0.11 

Destination: 192.168.0.200 

Reassembled IPv4 in frame: 3 
+ Data (1480 bytes) 


4 


Na seta de indicacáo 01 temos o tamanho total do pacote, no caso, 1500 bytes 


Na seta de indicacáo 02 temos o código de identificacáo do fragmento, no caso, 
47706, aqui podemos notar que temos o mesmo código ID do primeiro pacote o que 
indica que esse pacote é um fragmento do primeiro pacote. 


Na seta de indicacáo 03 temos o MF (More Fragments) setado o que nos indica que 
teremos mais fragmentos desse pacote. 


Na seta de indicação 04 temos o Fragment Offset com valor de 185, esse valor vai 
sendo maior a cada fragmento, dessa forma podemos organizar os pacotes por ordem 
crescente e saber qual a ordem correta. 


Vamos ver o terceiro pacote (terceira parte do fragmento) e destacar as partes mais 
importantes. 


+ Ethernet II, Src: Apple b8:di:af (a4:5e:60:b8:d1:af), Dst: Vmware 76:43:e1 (00:8c:29:76:43:e1) 
+ Internet Protocol Version 4, Src: 192.168.8.11, Dst: 192.168.0.200 
0100 .... = Version: 4 
. 0101 = Header Length: 20 bytes (5) 
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) 


Total Length: 1068 «———— 01 
Identification: @xba5a (47706) «—————— 02 
+ Flags: 0x0172 
Baget aa as aa = Reserved bit: Not set 
Daa aaa aaa aaan = Don't fragment: Not set À 03 
..0 = More fragments: Not set 


...8 0001 0111 0010 
Time to live: 64 
Protocol: ICMP (1) 
Header checksum: 6x38el [validation disabled] 

[Header checksum status: Unverified] 
Source: 192.168.0.11 
Destination: 192.168.0.200 
+ [3 IPv4 Fragments (4008 bytes): +1(1480), 42(1480), 43(1048)] 
+ Internet Control Message Protocol 


Fragment offset: 370 


Na seta de indicacáo 01 temos o tamanho total do pacote com valor de 1068, valor 
menor que 1500, se tratando de um fragmento isso poderia nos indicar que é a última 
parte do fragmento. 


Na seta de indicacáo 02 temos o código de identificacáo do fragmento, no caso, 


47706, aqui podemos notar que temos o mesmo código ID do primeiro e do segundo 
pacote o que indica que esse pacote faz parte do mesmo fragmento. 
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Na indicação 03 podemos notar que não temos nenhuma flag setada, também 
podemos notar que a flag MF (more fragments) está desabilitada, ou seja, não tem 
mais fragmentos e isso confirma nossa teoria de que essa é a última parte do 
fragmento. 


Na seta de indicação 04 temos o fragment offsec com valor de 370, conforme 
mencionei anteriormente a cada novo fragmento esse valor vai ficando maior, no 
primeiro pacote tinhamos 0, no segundo 185 e agora no último 370, se colocarmos 
em ordem crescente temos 0,185,370 ou seja, primeira parte, segunda parte e 
terceira parte. 


Resumo 


Um frame ethernet aceita no máximo 1500 bytes em seu payload, em sei payload 
geralmente ele carrega outro protocolo como por exemplo o protocolo ARP ou o 
protocolo IP. 


Quando o pacote IP tem mais de 1500 bytes ele é fragmentado (dividido em partes 
de no máximo 1500 bytes), os campos Identification do header IP são usados para 
identificar os fragmentos, o campo flags nos ajudam a saber se existe mais 
fragmentos através da flag MF (more fragments) e o fragment offset nos ajuda a 
organizar a ordem dos fragmentos. 


Na prática que vimos acima durante a comunicação ocorreu uma fragmentação onde 
tivemos 3 pacotes. Cada pacote tinha o ID como 47706 e o fragment offset do primeiro 
pacote foi 0, do segundo foi 185 e do terceiro foi 370, indicando a ordem correta dos 
fragmentos. 


RECAPITULANDO 


Antes de prosseguirmos com o próximo protocolo vamos só relembrar nosso contexto 
inicial. 


WWW 


Linux À 
Servidor (WEB) 
Endereço MAC: a4:5e:60:b8:cl:af (placa de rede) Endereço MAC: 00:0C:29:76:43:El (placa de rede) 
Endereço IP: 192.168.0.102 Endereço IP: 192.168.0.200 


Porta: 50234 dei 


A comunicacáo entre dois computadores diferentes onde temos o host cliente 
acessando o servidor web do host servidor. 


O frame ethernet tem o as informações que precisa assim como o endereço MAC e 
em seu payload está carregando um protocolo, no nosso exemplo ele carrega o 
protocolo IP, o protocolo IP tem as informações que precisa em seu header assim 
como o endereço IP e em seu payload está carregando um protocolo, nosso exemplo 
o protocolo TCP. 
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+ Frame 3: 78 bytes on wire (624 bits), 78 bytes captured (624 bits) on interface O 
+ Ethernet II, Src: Apple b8:d1:af (a4:5e:60:b8:d1:af), Dst: Vmware 76:43:e1 (00:0c:29:76:43:e1) 
+ Internet Protocol Version 4, Src: 192.168.0.11, Dst: 192.168.0.200 

Transmission Control Protocol, Src Port: 56104, Dst Port: 80, Seq: 0, Len: 0 


No exemplo acima podemos ter uma visão real da comunicação sendo formada em 
camadas, temos que olhar de cima pra baixo. 


Protocolo Ethernet — tem os endereços mac e em seu payload tem o protocolo IP 
Protcolo IP — tem os endereços IP e em seu payload tem o protocolo TCP 
Protocolo TCP — tem as portas 

Protocolo ethernet se comunica com endereços físicos (MAC Address) 

Protocolo IP se comunica com endereços lógicos (IP address) 

Protocolo TCP se comunica com portas 


Exemplo didático de encapsulamento 


Payload TCP 


| Header TCP | 


Payload IP 


Payload Ethernet 


Se trazermos isso para a teoria podemos ver que cada protocolo atua em uma 
camada, assim como vimos na teoria sobre modelos de referência, isso já começa a 
fazer mais sentido. 


Vamos continuar e conhecer o Protocolo TCP. 


PROTOCOLO TCP 


O protocolo TCP é um protocolo considerado confiável para transmissão de dados 
pois ele garante a entrega das informações. 


Diferente do protocolo IP o protocolo TCP nem sempre terá um payload. 
O segmento TCP se comunica com portas. 


Vamos conhecer a estrutura do Header TCP 
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HEADER TCP - RFC793 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Source Port | Destination Port 

PE E E E A ooo plo A piso pool O piso A piada pisado A O O A pila pisos A pla E 
| Sequence Number 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
l Acknowledgment Number 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Data | ITALE ss] 
Offset | Reserved IR|CI|SI|SI|YI|TI| Window 
| IGIK|HI|TINI|N| 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Checksum | Urgent Pointer 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Options | Padding | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Como podemos ver abaixo, temos o frame ethernet com origem do host cliente e 
destino host servidor. (sabemos disso olhando o Mac Address conforme visto 
anteriormente) 


Em seguida temos o Internet Protocol Version 4 (Protocolo IPv4), podemos notar que 
a origem temos o endereço IP do host cliente e no destino o endereço IP do host 
servidor. 


+ Ethernet II, Src: Apple_b8:d1:af (a4:5e:60:b8:d1:af), Dst: Vmware_76:43:e1 (00:0c:29:76:43:e1) 
+ Internet Protocol Version 4, Src: 192.168.0.11, Dst: 192.168.0.200 
Transmission Control Protocol, Src Port: 56104, Dst Port: 80, Seq: 0, Len: 0 

Source Port: 56104 

Destination Port: 80 

[Stream index: 0] 

[TCP Segment Len: 0] 

Sequence number: O (relative sequence number) 

[Next sequence number: O (relative sequence number)] 

Acknowledgment number: O 

1011 .... = Header Length: 44 bytes (11) 


Window size value: 65535 

[Calculated window size: 65535] 

Checksum: 0xc720 [unverified] 

[Checksum Status: Unverified] 

Urgent pointer: 0 

Options: (24 bytes), Maximum segment size, No-Operation (NOP), Window scale, No-Operation (NOP), 
[Timestamps] 


v 


E agora temos o Transmission Control Protocol mais conhecido como TCP, vamos 
analisar as informações do header TCP. 


Source port: Mostra a porta de origem (as portas podem ir de 0 a 65535) 

Destination Port: Mostra a porta de destino 

Sequence Number: Identifica o segmento TCP 

Acknowledgment: Faz a confirmação do segmento (sabe qual será o número de 
sequência do próximo segmento) 

Data offset: tamanho do header tcp 

Flags TCP: URG, ACK, PSH, RST, SYN, FIN 

Windows (Windows size) — determina a quantidade de bytes que o próximo segmento 
pode ter. 

Checksum — faz a verificação do header e payload e ainda do header IP. 
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Urgent Pointer — Quando a flag URG está ativa o conteúdo é colocado no início do 
payload afim de prioriza-lo. 

Options — serve para adicionar novas funcionalidades. 

Conhecendo as FLAGS TCP 

Cada flag tem sua função 

SYN - indica sincronizar, iniciar uma conexão entre os lados envolvidos. 


FIN — indica finalizar, ou seja, a conexão deve ser fechada 


RST — indica resetar, ou seja, quando a comunicação não é entendida ou tem algo 
errado. 


PSH — Indica que existem dados no payload TCP. 


ACK — faz a confirmação indicando que sabe qual será o próximo número de 
sequência. 


URG — Indica urgente, ou seja, o conteúdo deve ser priorizado. 
Vamos entender como ocorre uma conexáo TCP 


O TCP é orientado a conexão, isso significa que ele só transmite se garantir que uma 
conexáo foi estabelecida com sucesso. 


O estabelecimento dessa conexão inicial recebe o nome de three-way handshake. 


Three-way Handshake — é o nome dado a técnica utilizada para abrir uma 


conexão. 
Cliente Servidor (WEB) 
Cliente Servidor (WEB) 
Cliente Servidor Servidor (WEB) 
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Conforme podemos ver na imagem acima, antes do host cliente trocar informações- 
com o host servidor a conexão é estabelecida realizado o three-way handshake. 


O host cliente envia o pacote com a flag SYN indicando que quer sincronizar (iniciar 
uma conexão) 


O host servidor envia como resposta um pacote com as flags SYN/ACK confirmando 
o início da conexão. 


O host cliente envia o pacote com a flag ACK confirmando, com isso o three-way 
handshake é concluído e a partir dai os hosts iniciam a troca de informação. 


Vamos ver essa comunicação na prática usando o nosso analisador de protocolos 
Wireshark 


Na imagem abaixo temos 3 pacotes da nossa comunicação entre o host cliente e 
servidor, podemos ver nosso three-way handshake. 


No. Time Source Destination Protocol Length Info 
3 0.000689417 192.168.0.11 192.168.0.200 78 56104 — 80 [SYN] Seg=0 Win=65535 Len=0 MSS=1 
4 0.000753923 192.168.0.200 192.168.0.11 TCP 74 80 — 56104 [SYN, ACK] Seg=0 Ack=1 Win=28960 
5 0.001366446 192.168.0.11 192.168.0.200 TCP 66 56104 — 80 [ACK] Seq=1 Ack=1 Win=131712 Len= 


Vamos entender melhor 


No. Time Source Destination Protocol Length Info 
0. 000689417 192.168.0.11 192.168.0.200 78 56104 — 80 [SYN] Seg=0 Win=65535 Len=0 MSS=: 
4 0.000753923  192.168.0.200 192.168.0.11 TCP 74 80 — 56104 [SYN, ACK] Seq=0 Ack=1 Win=28960 
5 0.001366446 192.168.0.11 192.168.0.200 TCP 66 56104 - 80 [ACK] Seg=1 Ack=1 Win=131712 Len= 


+ Frame 3: 78 bytes on wire (624 bits), 78 bytes captured (624 bits) on interface 0 
+ Ethernet II, Src: Apple b8:di:af (a4:5e:60:b8:d1:af), Dst: Vmware 76:43:e1 (00:0c:29:76:43:e1) 
+ Internet Protocol Version 4, Src: 192.168.0.11, Dst: 192.168.0.200 


Source Port: 56104 4 
Destination Port: 80 

[Stream index: 0] 

[TCP Segment Len: 0] 

Sequence number: O (relative sequence number) 


[Next sequence number: 0 (relative sequence number)] 
Acknowledgment number: O 
1011 .... = Header Length: 44 bytes (11) 


Window size value: 65535 
[Calculated window size: 65535] 
Checksum: 6xc720 [unverified] 
[Checksum Status: Unverified] 
Urgent pointer: O 


+ Options: (24 bytes), Maximum segment size, No-Operation (NOP), Window scale, No-Operation (NOP), No-Operation (NOP), T: 
+ [Timestamps] 


Como podemos ver o host cliente (192.168.0.11) porta de origem 56104 está se 
comunicando com a porta 80 do host servidor (192.168.0.200) 


O campo que é importante focarmos é o campo de Flags pois vai indicar o 
comportamento da comunicação, no nosso caso podemos ver que temos a flag SYN 
ativada, indicando uma sincronização (início de conexão). 


Na imagem abaixo podemos ver que no header TCP, no campo de flags temos a flag 
SYN setada. 
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Source Port: 56104 

Destination Port: 80 

[Stream index: 0] 

[TCP Segment Len: 0] 

Sequence number: 0 (relative sequence number) 

[Next sequence number: 0 (relative sequence number)] 
Acknowledgment number: 0 

1011 .... = Header Length: 44 bytes (11) 


Reserved: Not set 

Nonce: Not set 

Congestion Window Reduced (CWR): Not set 
ECN-Echo: Not set 

Urgent: Not set 

Acknowledgment: Not set 

Push: Not set 

Reset: Not set 


© 
MR a a T A MI 


[TCP Flags: sssanonana S-] 


Vamos a resposta do servidor 


No. Time Source Destination Protocol Length Info 
à 3 0.000689417  192.168.0.11 — 192.168.0.200 TCP 78 56104 — 80 [SYN] Seq=0 Win=65: 
4 0.000753923 192.168.0.200 192.168.0.11 74 80 — 56104 [SYN, ACK] Seg=0 A 
5 0.001366446 192.168.0.11 192.168.0.200 TCP 66 56104 — 80 [ACK] Seq=1 Ack=1 | 


+ Ethernet II, Src: Vmware_76:43:e1 (00:0c:29:76:43:e1), Dst: Apple b8:di:af (a4:5e:60:b8:d1:af) 
+ Internet Protocol Version 4, Src: 192.168.0.200, Dst: 192.168.0.11 


Source Port: 80 

Destination Port: 56104 

[Stream index: 0] 

[TCP Segment Len: 0] 

Sequence number: 0 (relative sequence number) 

[Next sequence number: O (relative sequence number) ] 
Acknowledgment number: 1 (relative ack number) 

1010 .... = Header Length: 40 bytes (10) 


Window size value: 28960 


[Calculated window size: 28960] 

Checksum: 0x8252 [unverified] 

[Checksum Status: Unverified] 

Urgent pointer: O 
+ Options: (20 bytes), Maximum segment size, SACK permitted, Timestamps, No-Operation (NOP), Window scale 
+ [SEQ/ACK analysis] 
+ [Timestamps] 


Agora podemos notar que o host servidor com porta de origem 80 está respondendo 
ao host cliente com porta de destino 56104. 


No campo Flags podemos ver que o servidor está respondendo com as flags SYN / 
ACK ativas. 


Com isso o servidor confirma o estabelecimento da conexáo e agora o cliente precisa 
confirmar o estabelecimento da conexáo. 


Na imagem abaixo podemos ver o host cliente enviando a flag ACK ao servidor, 
concluindo assim o three-way handshake. 
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No. Time Source č Destination Protocol Length Info >... mao 
3 0.000689417 —192.168.0.11 192.168.0.208 TCP 78 56104 — 80 [SYN] Seg=0 Win=65535 
4 0.000753923 —192.168.0.200 192.168.0.11 TCP 74 80 > 56104 [SYN, ACK] Seq=0 Ack=1 


5 0.001366446 192.168.0.11 192.168.0.200 66 56104 — 80 [ACK] Seg=1 Ack=1 Win 


+ Ethernet II, Src: Apple b8:di:af (a4:5e:60:b8:d1:af), Dst: Vmware 76:43:€e1 (00:0c:29:76:43:e1) 
+ Internet Protocol Version 4, Src: 192.168.0.11, Dst: 192.168.0.200 
- Transmission Control Protocol, Src Port: 56104, Dst Port: 80, Seq: 1, Ack: 1, Len: O 

Source Port: 56104 sá 

Destination Port: 80 

[Stream index: 0] 

[TCP Segment Len: 0] 

Sequence number: 1 (relative sequence number) 

[Next sequence number: 1 (relative sequence number) ] 

Acknowledgment number: 1 (relative ack number) 

1000 .... = Header Length: 32 bytes (8) 

Flags: 0x010 (ACK) 

Window size value: 2058 

[Calculated window size: 131712] 

[Window size scaling factor: 64] 

Checksum: 0x9900 [unverified] 

[Checksum Status: Unverified] 

Urgent pointer: O 

» Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps 
+ [SEQ/ACK analysis] 


+ [Timectamnel 


Quando a comunicação é devidamente estabelecida através desse processo os hosts 
passam a trocar informações. 


Vamos ver o que acontece no nosso exemplo após a conexão ser estabelecida. 


No. Time Source Destination Protocol Length Info 
[Es 3 0.000689417  192.168.0.11 . 192.168.0.200 TCP — 78 56104 = 80 [SYN] Seg=0 Win=65535 L 
E E 0.000753923  192.168.0.200 192.168.0.11 TCP 74 80 > 56104 [SYN, ACK] Seg=0 Ack=1 
5 0.001366446  192.168.0.11 192.168.0.200 TCP 66 56104 > 80 [ACK] Seq=1 Ack=1 Win=1 


6 0.003539370 192.168.0.11 192.168.0.200 487 GET / HTTP/1.1 

4 
+ Internet Protocol Version 4, Src: 192.168.0.11, Dst: 192.168.0.200 
~ Transmission Control Protocol, Src Port: 56104, Dst Port: 80, Seq: 1, Ack: 1, Len: 421 

Source Port: 56104 

Destination Port: 80 

[Stream index: 0] 

[TCP Segment Len: 421] 

Sequence number: 1 (relative sequence number) 

[Next sequence number: 422 (relative sequence number)] 

Acknowledgment number: 1 (relative ack number) 

1000 .... = Header Length: 32 bytes (8) 

Flags: 0x018 (PSH, ACK) 


Window size value: 2058 


[Calculated window size: 131712] 

[window size scaling factor: 64] 

Checksum: 0xf2e1 [unverified] 

[Checksum Status: Unverified] 

Urgent pointer: O 
+ Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps 
+ [SEQ/ACK analysis] 
+ [Timestamps] 

TCP payload (421 bytes) 02 


03 


b 


Como podemos ver na imagem acima após a conexão ser estabelecida com sucesso 
(three-way handshake) o host cliente envia um segmento TCP que contém um 
payload. 


Como falamos no início, o protocolo TCP nem sempre irá carregar um payload, o 
exemplo disso foi o primeiro SYN do three-way handshake, lá podemos ver 
claramente que não existe payload. 


Normalmente nós vamos encontrar um payload no TCP quando a flag PSH estiver 
ativa. 
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Na imagem acima nós podemos ver que após a three-way handshake o cliente está” 
enviando as flags PSH, ACK conforme indica a seta 01, na indicacáo 02 podemos ver 
que agora temos um payload TCP com 421 bytes e na indicacáo 03 conseguimos ver 
o que ele está carregando, no caso, o protocolo HTTP. 


Se olharmos dentro do protocolo HTTP podemos ver a requisição do cliente ao 
servidor. 


Mas náo vamos nos aprofundar nisso agora, mais a frente vamos entender o 
protocolo HTTP de forma mais detalhada. 


Frame 6: 487 bytes on wire (3896 bits), 487 bytes captured (3896 bits) on interface O 
Ethernet II, Src: Apple b8:di:af (a4:5e:60:b8:d1:af), Dst: Vmware 76:43:e1 (00:0c:29:76:43:e1) 
Internet Protocol Version 4, Src: 192.168.0.11, Dst: 192.168.0.200 

Transmission Control Protocol, Src Port: 56104, Dst Port: 80, Seq: 1, Ack: 1, Len: 421 
Hypertext Transfer Protocol 


Host: 192.168.9.200r1n 
Connection: keep-aliveirin 
Upgrade-Insecure-Requests: 1\r\n 


User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10 14 6) AppleWebkKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.361rn 
Accept: text/html, application/xhtml+xml, application/xml;q=0.9, image/webp, image/apng,*/*;q=0.8,application/signed-exchange;v=b3rWn 
Accept-Encoding: gzip, deflateirín 


Accept-Language: en-US,en; q=0.9\r\n 

Arán 

[Full request URI: http://192.168.0.200/] 
[HTTP request 1/2] 

[Response in frame: 8] 

[Next request in frame: 10] 


Encerrando a conexão 


Quando os hosts desejam encerrar a conexão nós veremos a flag FIN em ação 


No. Time Source Destination Protocol Length Info 
13 1.604637854 192.168.0.11 192.168.0.200 66 56104 — 80 [FIN, ACK] Seg=777 Ack=825 
14 1.604831390 192.168.0.200 192.168.0.11 TCP 66 80 — 56104 [FIN, ACK] Seq-825 Ack=778 
15 1.605263534 192.168.0.11 192.168.0.200 TCP 66 56104 — 80 [ACK] Seg=778 Ack=826 wWin= 
4 


+ Frame 13: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface O 
+ Ethernet II, Src: Apple b8:di:af (a4:5e:60:b8:d1:af), Dst: Vmware 76:43:e1 (00:0c:29:76:43:e1) 
+ Internet Protocol Version 4, Src: 192.168.0.11, Dst: 192.168.0.200 


Source Port: 56104 

Destination Port: 80 

[Stream index: 0] 

[TCP Segment Len: 0] 

Sequence number: 777 (relative sequence number) 

[Next sequence number: 777 (relative sequence number)] 
Acknowledgment number: 825 (relative ack number) 

1000 .... = Header Length: 32 bytes (8) 


Window size value: 2048 

[Calculated window size: 131072] 

[window size scaling factor: 64] 

Checksum: 0x8b9a [unverified] 

[Checksum Status: Unverified] 

urgent pointer: O 
+ Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps 
+ [Timestamps] 


No exemplo o host cliente envia ao servidor a flag FIN/ACK, o host servidor responde 
com a flag FIN/ACK confirmando o encerramento da conexáo e o host cliente confirma 
que encerrou com a flag ACK. 
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Problema na conexáo 


Nós já vimos um exemplo bem sucedido de conexáo (three-way handshake) e 
também vimos um exemplo de encerramento de conexáo. 


Vamos ver agora um exemplo de problema na conexáo 


O host cliente vai tentar estabelecer uma conexáo com o host servidor 


No. Time Source Destination Protocol Length Info 
DO 192.168.0.4 192.168.0.200 TCP 


78 60839 — 80 [SYN] Seg=0 


192.168.0.200 192.168.0. TCP 54 80 ~> 60839 [R CK] 


+ Frame 1: 78 bytes on wire (624 bits), 78 bytes captured (624 bits) 
+ Ethernet II, Src: Apple b8:di:af (a4:5e:60:b8:d1:af), Dst: Vmware_76:43:e1 (00:0C:29:76:43:€1) 
+ Internet Protocol Version 4, Src: 192.168.0.4, Dst: 192.168.0.200 

Transmission Control Protocol, Src Port: 60839, Dst Port: 80, Seq: 0, Len: 0 


Source Port: 60839 


Destination Port: 80 

[Stream index: 0] 

[TCP Segment Len: 0] 

Sequence number: O (relative sequence number) 

[Next sequence number: O (relative sequence number)] 
Acknowledgment number: 0 

1011 .... = Header Length: 44 bytes (11) 


Window size value: 65535 

[Calculated window size: 65535] 

Checksum: 0x6557 [unverified] 

[Checksum Status: Unverified] 

Urgent pointer: 0 

Options: (24 bytes), Maximum segment size, No-Operation (NOP), Window scale, No-Operation (NOP), 
[Timestamps] 


Na imagem acima podemos ver o host cliente enviando um SYN para o host servidor 


No entanto, o servidor responde com RST / ACK e nada mais acontece. 


No. Time Source Destination Protocol Length Info 
1 0.000000000 192.168.0.4 192.168.0.200 TCP 78 60839 — 80 [SYN] Seq=0 Win=65535 
2 0.000026042 192.168.0.200 192.168.0.4 54 80 — 60839 [RST, ACK] Seq=1 Ack=1 


+ Frame 2: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) 

Ethernet II, Src: Vmware 76:43:e1 (00:0C:29:76:43:e1), Dst: Apple_b8:d1:af (a4:5e:60:b8:d1:af) 
Internet Protocol Version 4, Src: 192.168.0.200, Dst: 192.168.0.4 

Transmission Control Protocol, Src Port: 80, Dst Port: 60839, Seq: 1, Ack: 1, Len: O 


Source Port: 80 

Destination Port: 60839 

[Stream index: 0] 

[TCP Segment Len: 0] 

Sequence number: 1 (relative sequence number) 

[Next sequence number: 1 (relative sequence number) ] 
Acknowledgment number: 1 (relative ack number ) 

0101 .... = Header Length: 20 bytes (5) 


Window size value: 0 

[Calculated window size: 0] 

[Window size scaling factor: -1 (unknown)] 
Checksum: 0xb9f2 [unverified] 


[Checksum Status: Unverified] 
Urgent pointer: O 


Na imagem acima podemos ver o servidor respondendo com as flags RST / ACK o 
que indica que o servidor não conseguiu entender, nesse caso, isso ocorreu pois o 
servidor não estava com o serviço ativo. (a porta estava fechada) 
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RECAPITULANDO 
Antes de prosseguirmos com o próximo protocolo vamos só relembrar nosso contexto 
inicial. 
Ey 7 
Servidor (WEB) 
Endereço MAC: a4:5e:60:b8:cl:af (placa de rede) Endereço MAC: 00:0C:29:76:43:El (placa de rede) 
Endereço IP: 192168.0102 Endereço IP: 192168.0.200 
Porta: 50234 Porta: 80 


A comunicação entre dois computadores diferentes onde temos o host cliente 
acessando o servidor web do host servidor. 


O frame ethernet tem o as informações que precisa assim como o endereço MAC e 
em seu payload está carregando um protocolo, no nosso exemplo ele carrega o 
protocolo IP, o protocolo IP tem as informações que precisa em seu header assim 
como o endereço IP e em seu payload está carregando um protocolo, nosso exemplo 
o protocolo TCP que estabelece uma conexão com a porta 80 do servidor e carrega 
em seu payload outro protocolo, no nosso caso o protocolo HTTP. 


Frame 6: 487 bytes on wire (3896 bits), 487 bytes captured (3896 bits) on interface 0 


k 

+ Ethernet II, Src: Apple b8:d1:af (a4:5e:60:b8:di:af), Dst: Vnware_76:43:e1 (00:0c:29:76:43:e1) ENDEREÇOMAC ENLACE ETHERNET 
+ Internet Protocol Version 4, Src: 192.168.0.11, Dst: 192.168.0.200 ENDEREÇO IP REDE IPv4 

+ Transmission Control Protocol, Src Port: 56104, Dst Port: 80, Seg: 1, Ack: 1, Len: 421 PORTAS TRANSPORTE TCP 

b 


No exemplo acima podemos ter uma visão real da comunicação sendo formada em 
camadas, temos que olhar de cima pra baixo. 


Protocolo Ethernet — tem os endereços mac e em seu payload tem o protocolo IP 
Protcolo IP — tem os endereços IP e em seu payload tem o protocolo TCP 
Protocolo TCP — tem as portas e em seu payload tem o protocolo HTTP 


Protocolo ethernet se comunica com endereços físicos (MAC Address) 

Protocolo IP se comunica com endereços lógicos (IP address) 

Protocolo TCP se comunica com portas 

Protocolo HTTP é um protocolo a nível de aplicação que vamos ver no próximo tópico. 
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Exemplo didático de encapsulamento 


PROTOCOLO 
HTTP 


Payload TCP 


Payload IP 


Payload Ethernet 


PROTOCOLO 
HTTP 


Header TCP Payload TCP 


Header IP | Payload IP 


Header Ethernet Payload Ethernet 


CONCLUSÃO 


Ufa! Depois de um longo percurso chegamos ao famoso protocolo HTTP, tudo que 
fizemos até agora foi para entender o que acontece em uma simples comunicação de 
rede. 


Usamos como exemplo dois hosts se comunicando em uma rede local, mas antes de 
entrar em detalhes no protocolo HTTP vamos estudar como ocorre uma comunicação 
na internet. 

Dessa forma você irá conhecer outros protocolos importantes na internet assim como 
ter um entendimento mais claro de como as coisas funcionam debaixo dos panos 
antes de entendermos o funcionamento do protocolo HTTP. 


CONTEXTO - COMUNICAÇÃO NA INTERNET 
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Agora nosso contexto será de um host cliente acessando um servidor web na internet. 


LHE Servidor (WEB) 


«< Website: blog.grupobusinesscorp.com 
IP Público: 37.59.174.231 


KA e Internet 


Roteador: 192.168.0.1 
“TE e DE 


Cliente 


Endereço IP : 192.168.0.200 
Gateway : 192.168.0.1 


DNS : 8.8.8.8 
No exemplo acima temos nosso host cliente agora com um sistema operacional Linux 
e endereco IP 192.168.0.200 acessando um servidor na internet através do seguinte 
endereco blog.grupobusinesscorp.com. 


Como vimos anteriormente para acessarmos a internet ou redes diferentes 
precisamos de um roteamento, no caso, nosso gateway é o endereço IP do nosso 
roteador. Ele que vai se encarregar de enviar nosso pacote para a internet. 


Também podemos notar que na imagem acima temos um endereço de um servidor 
DNS (8.8.8.8), esse servidor DNS é um servidor de DNS público do Google. 


A partir de agora vamos entender como funciona o acesso via internet e conhecer 
outros protocolos, o UDP e o DNS. 


Nós acessamos o blog.grupobusinesscorp.com pelo nosso host cliente e fizemos a 
captura de tráfego da rede. Vamos entender. 


No. Time Source Destination Protocol Length Info 
1 0.000000000 ArrisGro_45:c4:0c Vmware 76:43:€1 60 Who has 192.168.0.200? Tell 192.168.0.1 
2 0.000021169 Vmware_76:43:el ArrisGro_45:c4:0c ARP 42 192.168.0.200 is at 00:0Cc:29:76:43:e1 
3 7.582145723  192.168.0.200 8.8.8.8 DNS 86 Standard query 0x06cb A blog.grupobusinesscorp.com 
4 7.582266308  192.168.0.200 8.8.8.8 DNS 86 Standard query ox6fd4 AAAA blog.grupobusinesscorp.c 
5 7.765375949 8.8.8.8 192.168.0.200 DNS 156 Standard query response 0x6fd4 AAAA blog.grupobusin 
6 7.765405271 8.8.8.8 192.168.0.200 DNS 102 Standard query response 0x06cb A blog.grupobusiness 
7 7.784578688 192.168.0.200 37.59.174.231 TCP 74 52100 + 80 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SAC 
8 8.079267597 37.59.174.231 192.168.0.200 TCP 74 80 - 52100 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 M 
9 8.079304840 192.168.0.200 37.59.174.231 TCP 66 52100 - 80 [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval= 
10 8.079463634 192.168.0.200 37.59.174.231 HTTP 156 GET / HTTP/1.1 
11 8.387009121 37.59,174,231 192.168.0.200 TCP 66 80 > 52100 [ACK] Seq=1 Ack=91 Win=14480 Len=0 TSval 
12 8.38/038003 3/.59.1/4.231 192.168.0.200 HTTP 333 HTTP/1.1 200 OK (text/html) 
13 8.387062353 192.168.0.200 37.59.174.231 TCP 66 52100 - 80 [ACK] Seq=91 Ack=268 Win=30336 Len=0 TSv 
14 8.387331027 192.168.0.200 Ad TCP 66 52100 — 80 [FIN, ACK] Seg=91 Ack=268 Win=30336 Len= 
15 8.694180031 37.59.174.231 192.168.0.200 TCP 66 80 > 52100 [FIN, ACK] Seg=268 Ack=92 Win=14480 Len= 


O primeiro pacote que aparece no nosso exemplo trás o protocolo ARP onde temos 
a comunicacáo entre nosso host cliente e o roteador da rede interna. 


Como já sabemos o ARP é usado para descobrir o endereço MAC dos hosts da rede 
local. 


Como podemos ver na tabela arp do host cliente podemos ver que temos o nosso 
roteador. 
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# arp -an 
? (192.168.0.1) at d4:ab:82:45:c4:0c [ether] on etho 


a | 


Uma vez que o ARP acontece teremos início a nossa comunicação com o host 
servidor na internet, vamos entender melhor. 


Antes vamos conhecer outro protocolo de transporte, o protocolo UDP. 
PROTOCOLO UDP 

O protocolo UDP assim como o TCP é um protocolo de transporte de dados, no 

entanto, ele não é confiável pois NAO garante a entrega dos dados, por outro lado e 

justamente por não ter esse controle ele acaba sendo um protocolo de entrega muito 


mais rápido. 


Outro detalhe é que ele não é orientado a conexão, ou seja, NÃO é necessário 
estabelecer uma conexão antes de começar a transmitir. 


Vamos conhecer o header do protocolo UDP 


Header UDP 


Como podemos ver o Header do protocolo UDP é muito simples, possuindo apenas 
porta de origem e destino, tamanho e checksum. 


Vamos ver um exemplo real 


Temos um frame ethernet com MAC de origem sendo nosso host cliente e MAC de 
destino sendo nosso roteador. 


Em seguida temos o protocolo IP que tem como origem o endereço IP do nosso 
host cliente e como destino o servidor DNS. 


E o protocolo IP carrega em seu payload o protocolo UDP 


Frame 3: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) on interface O 

Ethernet II, Src: Vmware 76:43:e1 (00:0c:29:76:43:e1), Dst: ArrisGro_45:c4:0c (d4:ab:82:45:c4:0c) 
Internet Protocol Version 4, Src: 192.168.08.200, Dst: 8.8.8.8 

User Datagram Protocol, Src Port: 51183, Dst Port: 53 


Source Port: 51183 €<-—— 
Destination Port: 53 4__— 
Length: 52 €-———— 
Checksum: 6xdic5 [unverified] 
[Checksum Status: Unverified] 
[Stream index: 0] 

Domain Name System (query) 


DESEC SECURITY SEGURANÇA DA INFORMAÇÃO LTDA 
O User Datagram Protocolo ou protocolo UDP se comunica usando portas assim 


como no protocolo TCP. 


Source port: No nosso exemplo, temos a porta de origem do nosso host cliente 
(51183), o número dessa porta assim como no TCP é gerado aleatoriamente. 


Destination port: No nosso exemplo temos a porta (53) do host servidor, que é o 
servidor DNS que estamos consultando. 


Length: Temos o tamanho total do segmento UDP 

E como payload o protocolo UDP carrega o Domain Name System ou DNS. 

Normalmente nós iremos encontrar o protocolo UDP em casos onde o foco é 

velocidade, como transmissões de áudio, vídeo, etc. Normalmente vamos encontrar 

o protocolo UDP em operação em serviços como o DNS, DHCP, SNMP etc. 
PROTOCOLO DNS 

Antes do DNS existir quando precisávamos acessar algum recurso como um site na 

internet, teríamos que saber o endereço IP. Imagina como seria difícil guardar 

centenas de números de endereços IPs toda vez que fossemos acessar algum site. 

Exemplo: 

Se não existisse o DNS, para acessar o facebook você teria que decorar o endereço 

157.240.222.35, depois se quisesse usar o google você teria que saber o endereço 

172.217.30.78. Pensa que loucura! Isso sem contar que o IP do servidor poderia 


mudar. 


O Domain Name System ou DNS surgiu justamente para resolver esse problema, 
basicamente ele faz a tradução de nome para endereço IP. 


Exemplo: 

Ao digitar facebook.com o host cliente pergunta ao servidor DNS qual o endereço IP 
do host facebook.com e ao encontrar a informação o DNS retorna com o endereço IP 
157.240.222.35. A partir dai a comunicação com o host se inicia. 

Quando configuramos um host para acessar a internet, seja manual ou 
automaticamente geralmente temos as configurações para indicar quais servidores 
DNS vamos utilizar. 


Essa configuração é importante pois indica qual servidor irá atuar para resolver os 
nomes dos hosts na internet. 


No nosso exemplo, nosso host cliente tem configurado como servidores de resolução 
de nomes os servidores de DNS público do google. (8.8.8.8) 


Av. Presidente Juscelino Kubitschek, 1455 - 4º Andar - São Paulo / SP - (11) 2124-3725 


99) 
U 


DESEC SECURITY SEGURANÇA DA INFORMAÇÃO LTDA 


Se o servidor DNS já tem as informações ele responde com o endereço IP, caso- 


contrário ele vai consultar os root servers até descobrir quem é o DNS responsável 
pelo endereço IP do host buscado. 


Os root servers são um conjunto de servidores que guardam as informações sobre 
os TLD (Top Level Domains) e a partir deles a resolução de nomes é possível. Todo 
servidor DNS deve ter em suas configurações os endereços de todos os root severs. 


Vamos ver isso na prática 


GJ E Servidor (WEB) 


« Website: blog.grupobusinesscorp.com 
IP Público: 37.59.174.231 


A Internet 


(9) < 


Roteador: 192.168.0.1 
4 
A me 


Cliente 


Endereço IP : 192.168.0.200 
Gateway : 192.168.0.1 


Nosso host cliente está acessando o site blog.grupobusinesscorp.com, antes da 
comunicação ser estabelecida (three-way handshake) o protocolo DNS entra em ação 
para descobrir o endereço IP do endereço blog.grupobusinesscorp.com. 


Y 

Y 
GT. a A i 
7 7.784578688 192. 168. 0.200 37. 59. 174.231 TCP 74 52100 — 80 [SYN] Seg=0 Win=29200 Len= 7 MSS=1460 SAC 
8 8.079267597 37.59.174.231 192.168.0.200 TCP 74 80 - 52100 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 N 
9 8.079304840 192.168.0.200 37.59.174.231 TCP 66 52100 — 80 [ACK] Seg=1 Ack=1 Win=29312 Len=0 TSval= 


Entendendo a comunicacáo para consulta DNS 


Abaixo podemos os detalhes 


3 7.582145723 192.168.0.200 86 Standard query 0x06cb A blog.grupobusinesscorp.com 

4 7.582266308 192.168.0.200 8.8.8.8 DNS 86 Standard query 0x6fd4 AAAA blog.grupobusinesscorp.c 
| 5 7.765375949 8.8.8.8 192.168.0.200 DNS 156 Standard query response O0x6fd4 AAAA blog.grupobusin 

6 7.765405271 8.8.8.8 192.168.0.200 DNS 102 Standard query response 0x06cb A blog.grupobusiness 
4 + 


+ Frame 3: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) on interface O 
+ Ethernet II, Src: Vmware 76:43:e1 (00:0c:29:76:43:e1), Dst: ArrisGro 45:c4:0c (d4:ab:82:45:c4:0c) 4—— 01 
+ Internet Protocol Version 4, Src: 192.168.0.200, Dst: 8.8.8.8 +——— 02 
+ User Datagram Protocol, Src Port: 51183, Dst Port: 53 4«———— 03 
- Domain Name System (query) 
Transaction ID: 0x06cb 
Flags: 0x0100 Standard query 
Questions: 1 
Answer RRs: O 
Authority RRs: O 
Additional RRs: O 
- Queries 
~ blog.grupobusinesscorp.com: type A, class IN 
Name: blog.grupobusinesscorp.com 4«———— 04 
[Name Length: 26] 


[Label Count: 3] 
Type: A (Host Address) (1) «—_————— 05 
Class: IN (0x0001) 

[Response In: 6] 


Na seta de indicacáo 01 podemos ver nosso host cliente enviando nosso frame 
ethernet ao nosso roteador. O payload desse frame ethernet possuí o protocolo IP. 


Av. Presidente Juscelino Kubitschek, 1455 - 4º Andar - São Paulo / SP - (11) 2124-3725 


U2 


DESEC SECURITY SEGURANÇA DA INFORMAÇÃO LTDA 


Na seta de indicação 02 temos o protocolo IP onde nosso host cliente está se 
comunicando com o servidor DNS (8.8.8.8). O payload desse pacote IP temos o 
protocolo UDP. 


Na seta de indicação 03 temos o protocolo UDP onde nossa porta de origem 51183 
se comunica com a porta de destino 53 do servidor DNS. 


A consulta DNS normalmente funciona na porta 53 UDP 
No payload do segmento UDP temos o DNS. 


Na seta de indicação 04 podemos ver a consulta DNS ocorrendo, onde o servidor 
DNS vai resolver o nome blog.grupobusinesscorp.com 


Na seta de indicação 05 temos o tipo de consulta sendo feita, no nosso caso tipo A 
que significa Host Address ou endereço do host. 


Vamos ver os detalhes na resposta do servidor 


6 7.765405271 8.8.8.8 192.168.0.200 102 Standard query response 0x06cb A blog.grupobusiness 
7 7.784578688 192.168.0.200 3/.59.174.231 TCP 74 52100 — 80 [SYN] Seg=0 Win=29200 Len=0 MSS=1460 SAC 
k 
+ Frame 6: 102 bytes on wire (816 bits), 102 bytes captured (816 bits) on interface O 
+ Ethernet II, Src: ArrisGro_45:c4:0c (d4:ab:82:45:c4:0c), Dst: Vmware 76:43:e1 (00:0Cc:29:76:43:e1) +—— 01 
+ Internet Protocol Version 4, Src: 8.8.8.8, Dst: 192.168.0.200 «——— 02 
+ User Datagram Protocol, Src Port: 53, Dst Port: 51183 <—— 03 
~ Domain Name System (response) «——_—_— 
Transaction ID: 0x06cb 
Flags: 0x8180 Standard query response, No error 
Questions: 1 
Answer RRs: 1 
Authority RRs: O 
Additional RRs: 0 
Queries 
~ Answers pas 
- blog.grupobusinesscorp.com: type A, class IN, addr 37.59.174.231 
Name: blog.grupobusinesscorp.com 
Type: A (Host Address) (1) 
Class: IN (0x0001) 
Time to live: 3599 
Data length: 4 
Address: 37.59.174.231 <—— 04 
[Request In: 3] 
[Time: 0.183259548 seconds] 


Na seta de indicação 01 podemos ver o nosso roteador enviando o frame ethernet 
com destino ao nosso host cliente. 


Na seta de indicação 02 temos o servidor DNS (8.8.8.8) como origem e como destino 
nosso host cliente (192.168.0.200) 


Na seta de indicação 03 temos a porta 53 como origem e a porta 51183 como destino. 


E por último temos a resposta da consulta DNS realizada anteriormente, no nosso 
caso, no campo Answers temos o endereço IP do host blog.grupobusinesscorp.com. 


Uma vez que temos o endereço IP do site a comunicação é estabelecida através do 
famoso three-way handshake. 
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6 7.765405271 8.8.8.8 192.168.0.200 DNS 102 Standard query response 0x06cb A blog.grupobusiness 

7 7.784578688 192.168.0.200 3/.59.174.231 TCP 74 52100 — 80 [SYN] Seg=0 Win=29200 Len=0 MSS=1460 SAC 

8 8.079267597 Es ret ba bed pe Jal 192.168.0.200 TCP 74 80 — 52100 [SYN, ACK] Seg=0 Ack=1 Win=14480 Len=0 M 

9 8.079304840 192.168.0.200 37.59.174.231 TCP 66 52100 — 80 [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval= 
10 8.079463634 192.168.0.200 37.59.174. 231 HTTP 156 GET / HTTP/1.1 


Na imagem acima podemos ver claramente que após a resposta do servidor DNS 
com o endereço IP do host de destino iniciamos uma comunicação do nosso host 
cliente com o endereço IP do site. 


RECAPITULANDO 


Desde o início da nossa jornada em entender o funcionamento de uma comunicação 
de rede, pudemos ver de forma clara a comunicação em uma rede local e 
posteriormente uma comunicação na internet. 


Com base no nosso contexto prático conseguimos compreender o funcionando dos 
principais protocolos envolvidos em uma comunicação de rede como por exemplo os 
protocolos ETHERNET, ARP, IP, TCP, UDP e DNS. 


Antes de continuar vamos conhecer o protocolo HTTP. 


PROTOCOLO HTTP 


Não tem como falar de web sem mencionar o protocolo HTTP, praticamente tudo que 
acessamos atualmente na web como sites, e-commerce, aplicações web etc só é 
possível graças ao protocolo HTTP. 


Inclusive nosso exemplo de comunicação entre dois hosts continha um acesso a um 
site e vimos todo processo de comunicação acontecendo até chegar ao payload que 
carregava o protocolo HTTP. 


Na captura abaixo nós podemos ver que o payload do protocolo TCP é o protocolo 
HTTP (Hypertext Transfer Protocol). 


E 079463634 192.168.0.200 31.59.174.231 156 GET / HTTP/1.1 
11 8.387009121 3/.59.1/4.231 192.168.0.200 TCP 66 80 — 52100 [ACK] Seg=1 Ack=91 Win=14 
12 8.387038003 37.59.174.231 192.168.0.200 HTTP 333 HTTP/1.1 200 OK (text/html) 
13 8.387062353 192.168.0.200 3/.59.174.231 TCP 66 52100 — 80 [ACK] Seg=91 Ack=268 Win= 
AA R 2997294097 409 188 A PAA 27 GO 474 954 TCD BR BJAAA — QA [CTM AWI Can—04 Arl- 2AR 


+ Frame 10: 156 bytes on wire (1248 bits), 156 bytes captured (1248 bits) on interface O 

+ Ethernet II, Src: Vmware_76:43:e1 (00:0c:29:76:43:e1), Dst: ArrisGro_45:c4:0c (d4:ab:82:45:c4:0c) 
+ Internet Protocol Version 4, Src: 192.168.0.200, Dst: 37.59.174.231 

+ Transmission Control Protocol, Src Port: 52100, Dst Port: 80, Seq: 1, Ack: 1, Len: 90 


GET / HTTP/1.1Ar4n 
+ [Expert Info (Chat/Sequence): GET / HTTP/1.1\r\n] 
Request Method: GET 
Request URI: / 
Request Version: HTTP/1.1 
Host: blog.grupobusinesscorp.comirin 
User-Agent: curl/7.65.1xr4n 
Accept: */*Airin 
rim 
[Full request URI: http://blog.grupobusinesscorp.com/] 
[HTTP request 1/1] 
[Response in frame: 12] 


Av. Presidente Juscelino Kubitschek, 1455 - 4º Andar - São Paulo / SP - (11) 2124-3725 


DESEC SECURITY SEGURANÇA DA INFORMAÇÃO LTDA 


E como resposta o servidor retorna 


12 8.387038003 alcalde al 192.168.0.200 333 HTTP/1.1 200 OK (text/html) 


| 13 8. 387062353 192.168.0.200 37.59.174. 231 TCP 66 52100 — 80 [ACK] Sea=91 Ack=2 
4 


Frame 12: 333 bytes on wire (2664 bits), 333 bytes captured (2664 bits) on interface O 

Ethernet II, Src: ArrisGro 45:c4:0c (d4:ab:82:45:c4:0c), Dst: Vmware 76:43:e1 (00:0c:29:76:43:e1) 
Internet Protocol Version 4, Src: 37.59.174.231, Dst: 192.168.0.200 

Transmission Control Protocol, Src Port: 80, Dst Port: 52100, Seg: 1, Ack: 91, Len: 267 

Hypertext Transfer Protocol 

+ 


Date: Wed, 07 Feb 2018 13:48:02 GMT\r\n 
Server: Apachetrin 
Last-Modified: Tue, 07 Feb 2017 14:16:05 GMTirin 
ETag: "bf8a8-1b-547f163807ec8"1rin 
Accept-Ranges: bytesirin 
Content-Length: 27\r\n 
Vary: Accept-Encodingirún 
Content-Type: texthtmlirin 
irán 
[HTTP response 1/1] 
[Time since request: 0.307574369 seconds] 
[Request in frame: 10] 
[Request URI: http://blog.grupobusinesscorp.com/] 
File Data: 27 bytes 
Line-based text data: text/html (1 lines) 
Blog desativado no momenton 


4 


Não se preocupe se você não entendeu nada, vamos estudar um pouco o 
funcionamento do protocolo HTTP antes de rever os exemplos aplicado a redes. 


O protocolo HTTP funciona com trocas de requisições entre cliente e servidor, 
normalmente do lado do cliente nos temos o navegador de internet e do lado do 
servidor nós temos os servidores web. 


O cliente ainda poderia ser alguma aplicação cliente que entenda o protocolo HTTP, 
não necessariamente precisa ser um navegador. Exemplo: curl. 


No lado dos servidores web podemos ter várias opções como IIS da Microsoft, 
Apache que é open source, nginx etc. 


Cliente (Browser) Servidor (Web Server) 


/a 


O protocolo HTTP funciona com requisições, por exemplo, as de solicitações são 
chamadas HTTP Request e as de respostas sáo chamadas de HTTP Response. 


Abaixo nós temos um exemplo de HTTP Request sendo enviado ao servidor e um 
HTTP Response sendo respondido pelo servidor. 
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mu HTTP Request LN 
CGE 


Cliente Servidor (WEB) 

O emea Ch 
—— O —— q 

Cliente HTTP Response servidor (WEB) 


O protocolo HTTP suporta vários métodos tais como GET, POST, HEAD, PUT, 
DELETE, OPTIONS e cada método tem uma função. 


Os mais utilizados sáo o método GET para requisitar recursos, também é comum 
encontrarmos o método POST em envio de dados como por exemplo em páginas de 
login. 


A estrutura do HTTP é composta de um Header e um Body, normalmente em resposta 
de um GET bem sucedido temos o recurso vindo no Body e quando utilizamos o 
método POST para enviar um dado normalmente o colocamos no Body. 


Body 


Toda requisição recebe um código de resposta conhecido como status, existem vários 
códigos de status mas vamos falar apenas dos mais usados. 


200 OK - A requisição foi bem-sucedida 

301 Moved Permanently - O recurso foi movido (redirecionamento) 

403 Forbidden - O cliente não tem permissão para acessar o recurso solicitado 
404 Not Found - O recurso solicitado não foi encontrado 

500 Internal Server Error - Ocorreu um erro no lado do servidor 


Agora que sabemos isso, vamos voltar ao nosso exemplo 


[] SEITAS ET LAR 
_ _ __ _——> 
(ma re 


Cliente Servidor (WEB) 
O ema Ci 
Cliente HTTP Response Servidor (WEB) 
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No HTTP Request foi utilizado “GET / HTTP/1.1” 
GET — Método para requisitar um recurso 


URI — O recurso requisitado foi /, no caso, a barra indica a raiz, ou seja, a página 
principal do site, no entanto isso poderia ser qualquer coisa como por exemplo 
login, /file.php, /imagem.png etc. 


HTTP/1.1 — indica a versáo do protocolo utilizada. 


No HTTP Response o servidor respondeu a requisição com “HTTP/1.1 200 OK”, ou 
seja, com um código de resposta (status) 


200 OK - indicando que tudo correu bem, normalmente no corpo (body) vem a 
resposta com o conteúdo do recurso solicitado. 


Você pode ver a especificação completa do protocolo HTTP na rfc2616 
(https://tools.ietf.org/html/rfc2616). 


EXEMPLO PRÁTICO DO PROTOCOLO HTTP 


Abrimos o navegador no computador e acessamos um determinado site, a captura 
abaixo mostra o protocolo HTTP em ação na rede. 


No. Time Source Destination Protocol Length Info 
5 0.253266818 192.168.0.200 37.99. 174.232 399 GET / HTTP/1.1 


9 0.567951871 37.59.174. 232 192.168.080.209 HTTP 3560 HTTP/1.1 200 OK (text/html) 


4 


+ Frame 5: 399 bytes on wire (3192 bits), 399 bytes captured (3192 bits) on interface O 

+ Ethernet II, Src: Vmware 76:43:€e1 (00:0c:29:76:43:€1), Dst: ArrisGro_45:c4:0c (d4:ab:82:45:c4:0c) 
+ Internet Protocol Version 4, Src: 192.168.0.200, Dst: 37.59.174.232 

+ Transmission Control Protocol, Src Port: 56708, Dst Port: 80, Seq: 1, Ack: 1, Len: 333 


—- 


+ [Expert Info (Chat/Sequence): GET / HTTP/1.1Xrkn] 
Request Method: GET +——————— 
Request URI: / ———— 
Request Version: HTTP/1.1 <«—————— 
—> Host: ww.grupobusinesscorp.comirAn ap 
—> User-Agent: Mozilla/5.0 (X11; Linux x86 64; rv:60.0) Gecko/20100101 Firefox/60.0%rin 
—> Accept: text/html, application/xhtml+xml, application*xml;q=0.9,*/*;q=0.8r4n 
—> Accept-Language: en-US, en;q=0.5\r\n 
—> Accept-Encoding: gzip, deflate\r\n 

DNT: 1\r\n 
—> Connection: keep-alive\r\n 

Upgrade-Insecure-Requests: 1\r\n 

\r\n 

[Full request URI: http://www.grupobusinesscorp.com/] 

[HTTP request 1/3] 

[Response in frame: 9] 

[Next request in frame: 12] 


Podemos ver o HTTP Request usando método GET na raiz (/) e na versão 1.1 do 
HTTP. 


Host — especifica o host (o webserver pode ter múltiplos sites) 


User-Agent — Identifica o cliente que está acessando, no nosso caso, o navegador 
Firefox em um sistema operacional Linux. 


Accept — especifica o tipo esperado da resposta (no nosso caso text/html) 
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Vamos ver a resposta do servidor 


9 0.567951871 37.59.174.232 192.168.0.200 3560 HTTP/1.1 200 OK (text/html) 
11 0.667119604 192.168.0.200 37.59.174.232 HTTP 389 GET /css/bootstrap.min.css HTTP/1.1 


Date: Wed, 15 Feb 2017 02:46:48 GMT\r\n 

—> Server: Apacheirin 
Last-Modified: Tue, 07 Feb 2017 13:15:28 GMT\r\n 
ETag: "bf8a8-39fb-547F08ab622b9"XMr4n 
Accept-Ranges: bytesirin 
Vary: Accept-Encodingirín 


Content-Encoding: gzipirin 

— Content-Length: 3170\r\n 
Keep-Alive: timeout=5, max=100\r\n 
Connection: Keep-Alive\r\n 

— Content-Type: text/html\r\n 


\r\n 


[HTTP response 1/3] 
[Time since request: 0.314683053 seconds] 


[Request in frame: 5] 


Código html da página 


[Next request in frame: 12] 


[Next response in frame: 25] 


[Request URI: http://www.grupobusinesscorp.com/] 
Content -encoded entity body (gzip): 3170 bytes 
File Data: 14843 bytes 

- Line-based text data: text/html (348 lines) 


14843 bytes 


inanma Lato 


Podemos ver o HTTP Response retornando o status com código 200 OK, indicando 
assim que tudo correu bem. 


Server: Trás informações sobre o servidor, no nosso caso, o servidor diz ser um 
Apache. 


Em content-length temos o tamanho em bytes da resposta e no content-type temos 
o tipo de conteúdo como sendo texto e html. 


No body temos o código html da página inicial requisitada 


- Line-based text data: text/html (348 lines) 
<!DOCTYPE html>+n 
<html lang="en">An 


An 
<head>4n 
AM 
<meta charset="utf-8">1n 
<meta http-equiv="X-UA-Compatible" content="IE=edge">in 
<meta name="viewport" content="width=device-width, initial-scale=1">n 
<meta name="description" content="">in 
<meta name="author" content="">in 
An 
<title>Business</title>in 
An 
<!-- Bootstrap Core CSS -->in 
<link href="css/bootstrap.min.css" rel="stylesheet">1n 
An 
<!-- Custom CSS -->An 
<link href="css/stylish-portfolio.css” rel="stylesheet">in 
An 


<!-- Custom Fonts -->1n 
<link href="font-awesome/css/font-awesome.min.css" rel="stylesheet" type="text/css">in 


Nesse momento o navegador do cliente tem a capacidade de processar o código e 
exibir a página corretamente ao cliente. 
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Business - Mozilla Firefox 
Ele Edt View History Bookmarks Jools Help 
Business x|+ 


(> ea 


[© www.grupobusinesscorp.com .. Y MO = 


Ine: 


MONTANDO O QUEBRA CABEÇA 


Nesse momento você é capaz de compreender como uma comunicação de rede 
funciona nos bastidores. 


Rede Local 
z 
vae a 
Cliente Servidor (WEB) 
Endereço MAC: a4:5e-60:b8:cl:af (placa de rede) Endereço MAC: 00:0C:29:76:43:El (placa de rede) 
Endereço IP: 192.168.0.102 Endereço IP: 192168.0.200 
Porta: 50234 Porta: 80 


Na comunicação acima normalmente teremos os seguintes protocolos envolvidos: 
Ethernet, ARP, IP, TCP, HTTP 


Acesso a Internet 


Av. Presidente Juscelino Kubitschek, 1455 - 4º Andar - São Paulo / SP - (11) 2124-3725 


DESEC SECURITY SEGURANÇA DA INFORMAÇÃO LTDA 


GJ E Servidor (WEB) 
> 


+ Website: blog.grupobusinesscorp.com 
IP Público: 37.59.174.231 


2 internet 


D < 


Roteador: 192.168.0.1 


A 
Cliente 


Endereço IP : 192.168.0.200 
Gateway : 192.168.0.1 
DNS : 8.8.8.8 


Na comunicacáo acima normalmente teremos os seguintes protocolos envolvidos: 


Ethernet, IP, UDP, TCP, DNS, HTTP. 


PROTOCOLO ICMP 


O protocolo Internet Control Message Protocol ou ICMP é um protocolo de alerta por 
mensagens, ele emite avisos sobre a situação da rede. 


A estrutura básica do ICMP é simples, composta de tipos e códigos, cada um com 
sua função. 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Type | Code l Checksum 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Existem vários tipos e códigos, mas vamos nos concentrar nos principais 
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11 - time exceeded 


3 - destination unreachable 0 — network unreachable | Rede não encontrada 

i 1 — host unreachable ' Host não encontrado 
2 — protocol unreachable Protocolo não encontrado 

'3-— port unreachable ' Porta não encontrada 


Se quiser ver a lista completa acesse https://www.iana.org/assignments/icmp- 


parameters/icmp-parameters.xhtml. 


Vamos ver alguns exemplos 
Ping 


O ping é comumente utilizado para verificar a comunicação de rede entre hosts 
(desde que o protocolo ICMP não esteja bloqueado). 


O ping faz isso através do protocolo ICMP 


Como vimos na tabela acima se o protocolo ICMP utilizar o tipo 8 com código O ele 
estará enviando o chamado echo request (ping) 


Como resposta o host vai utilizar o tipo O com código O mais conhecido como echo 
reply. 


Essa resposta permite primeiramente saber que a comunicação está ok, mas além 
disso pode ser utilizada para medir o tempo de resposta e detectar problemas de 
lentidão ou problemas de rotas. 


No nosso exemplo o host cliente disparou um ping para o host servidor através do 
seguinte comando: 


ping -c 1 192.168.0.200 (a opção -c 1 indica para enviar apenas um pacote) 


No. Time Source Destination Protocol Length Info 


1 0.000000 192.168.0.4 192.168.0.200 98 Echo (ping) request id=0xd50f, seq=0/0, ttl=64 
2 0.000036 192.168.0.200 192.168.0.4 ICMP 98 Echo (ping) reply id=0xd50f, seq=0/0, ttl=64 


+ Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) 
+ Ethernet II, Src: Apple_b8:d1:af (a4:5e:60:b8:d1:af), Dst: Vmware 76:43:e1 (00:0c:29:76:43:e1) 
+ Internet Protocol Version 4, Src: 192.168.0.4, Dst: 192.168.0.200 

Internet Control Message Protocol 


Type: 8 (Echo (ping) request) «—— 
Code: 0 <— 

Checksum: Ox6f1e [correct] 

[Checksum Status: Good] 


Identifier (BE): 54543 (Oxd50f) 

Identifier (LE): 4053 (0x0fd5) 

Sequence number (BE): O (0x0000) 

Sequence number (LE): O (0x0000) 

[Response frame: 2] 

Timestamp from icmp data: Aug 7, 2019 10:21:36.432925000 -03 
[Timestamp from icmp data (relative): 0.001150000 seconds] 

+ Data (48 bytes) 
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Na imagem acima temos o host cliente (192.168.0.4) enviando um ping para o host 


servidor (192.168.0.200) 


Como podemos ver no payload do protocolo IP temos o ICMP no qual está usando o 
Type: 8e o Code: O o que indica um echo request (ping). 


Em seguida temos a resposta do servidor 


No. Time Source Destination Protocol Length Info 
— 1 0.000000 192.168.0.4 192.168.0.200 ICMP 98 Echo (ping) request id=0xd50f, seq=0/0, ttl=64 
a 2 0.000036 192.168.0.200 192.168.0.4 98 Echo (ping) reply id=0xd50f, seq=0/0, tt1=64 


+ Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) 
+ Ethernet II, Src: Vmware_76:43:e1 (00:0Cc:29:76:43:e1), Dst: Apple_b8:d1:af (a4:5e:60:b8:d1:af) 
+ Internet Protocol Version 4, Src: 192.168.0.200, Dst: 192.168.0.4 

Type: O (Echo (ping) reply) «—— 

Code: O «— 

Checksum: 0x771e [correct] 

[checksum Status: Good] 

Identifier (BE): 54543 (0xd5of) 

Identifier (LE): 4053 (0xofd5) 

Sequence number (BE): O (0x0000) 

Sequence number (LE): © (0x0000) 

[Request frame: 1] 

[Response time: 0.036 ms] 

Timestamp from icmp data: Aug 7, 2019 10:21:36.432925000 -03 

[Timestamp from icmp data (relative): 0.001186000 seconds] 

+ Data (48 bytes) 


Como podemos ver no payload do protocolo IP temos o ICMP no qual está usando o 
Type: O e o Code: O o que indica um echo reply (resposta do ping). 


Abaixo podemos ver a resposta no utilitário, temos o TTL=64 o que indica que o 
servidor provavelmente usa um sistema Linux. 


fi ricardolongatto — -bash — 83x16 
secbook:~ ricardolongatto$ ping -c 1 192.168.0.200 
PING 192.168.0.200 (192.168.0.200): 56 data bytes 
64 bytes from 192.168.0.200: icmp_seq=0 ttl=64 time=0.546 ms 


--- 192.168.0.200 ping statistics --- 
1 packets transmitted, 1 packets received, 0.0% packet loss 
round-trip min/avg/max/stddev = 0.546/0.546/0.546/0.000 ms 


Importância do Protocolo ICMP na prática 


Nosso próximo exemplo visa demonstrar a importância do protocolo ICMP em uma 
rede. 


Vamos imaginar que agora nosso host cliente utilizando o protocolo UDP tente se 
comunicar com uma porta fechada no host servidor. 


Lembrando que diferente do protocolo TCP, o protocolo UDP não possui nenhum 
tipo de controle, dessa forma o protocolo UDP sozinho não tem capacidade de 
avisar sobre o que acontece na comunicação. 


É justamente aí que o protocolo ICMP entra em ação, através do tipo 3 ele pode 
informar o que ocorreu com a comunicação. 
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No exemplo abaixo temos o exemplo da resposta do host servidor a requisição 
iniciada pelo host cliente. 


O host cliente através do protocolo UDP tentou se conectar na porta 3333 do 
servidor, porém essa porta estava fechada, então o servidor usa o protocolo ICMP 
para avisar o host cliente, conforme podemos ver abaixo. 


No. Time Source Destination Protocol Length Info 
1 0.000000 192.168.0.200 192.168.0.4 71 Destination unreachable (Port unreachable) 
2 0.000104 192.168.0.200 192. 8.0.4 Ñ esti ic eachable (Port eachable) 


Frame 1: 71 bytes on wire (568 bits), 71 bytes captured (568 bits) 
Ethernet II, Src: Vmware 76:43:e1 (00:0c:29:76:43:e1), Dst: Apple b8:di:af (a4:5e:60:b8:d1:af) 
Internet Protocol Version 4, Src: 192.168.0.200, Dst: 192.168.0.4 
Internet Control Message Protocol 
Type: 3 (Destination unreachable) «—— 
Code: 3 (Port unreachable) 
Checksum: 0x7f34 [correct] 
[Checksum Status: Good] 
Unused: 00000000 
+ Internet Protocol Version 4, Src: 192.168.0.4, Dst: 192.168.0.200 «— 
~ User Datagram Protocol, Src Port: 58789, Dst Port: 3333 «—— 
Source Port: 58789 
Destination Port: 3333 
Length: 9 
Checksum: 0x3314 [unverified] 
[Checksum Status: Unverified] 
[Stream index: 0] 
+ Data (1 byte) 


No exemplo acima podemos ver que o protocolo ICMP utiliza o Type: 3 (Destination 
unreachable) e com Code: 3 (Port unreachable) o que faz muito sentido, ele nos 
informa que a porta náo foi encontrada. 


Dessa forma sabemos que aquela porta UDP náo está aberta no servidor. 
Outro exemplo, podemos enviar um ping para um host inexistente na rede 


root@pentest: ~ 


File Edit View Search Terminal Help 
:~# ping -c 1 192.168.0.55 
PING 192.168.0.55 (192.168.0.55) 56(84) bytes of data. 


From 192.168.0.200 icmp seq=1 Destination Host Unreachable 


host inexistente 


- 192.168.0.55 ping statistics ==- 
1 packets transmitted, O received, +1 errors, 100% packet loss, time Oms 


Como resultados temos um Destination Host Unreachable que veio do protocolo 
ICMP de Tipo 3 com Código 1 indicando que o host de destino náo foi encontrado. 


Se o protocolo ICMP náo avisasse náo teríamos nenhum retorno sobre o que 
ocorreu na rede. 


Traçando a rota com ICMP 
Vamos ver outra grande utilidade do protocolo ICMP, conforme vimos anteriormente 


temos um ICMP do tipo 11 com código O. Esse tipo geralmente é utilizado quando o 
TTL se torna O. 
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Mas antes de seguir em frente, vamos relembrar o que é o TTL, o TTL é Time to 
Live ou tempo de vida do pacote IP. Isso serve justamente para que o pacote não 
fique vagando eternamente pela rede. 


Cada vez que o pacote IP passa por um roteador (hop) o seu TTL é decrementado 
(-1) até se tornar 0, quando esse valor se torna O o roteador descarta o pacote para 
evitar que ele fique vagando eternamente. 


O TTL é um campo do protocolo IP e cada sistema operacional implementa um 
valor padrão para esse campo, por exemplo, no Windows o TTL padrão é 128 já nos 
sistemas Linux o valor padrão é 64, já os Unix normalmente utilizam 255. De 
qualquer forma esses valores podem ser alterados pelo usuário. 


Agora que nós já refrescamos a memória em relação ao TTL, vamos voltar ao 
protocolo ICMP. 


Quando o TTL se torna O normalmente o roteador utiliza o protocolo ICMP para 
avisar, ele então utiliza o ICMP de tipo 11 e código 0. 


No exemplo abaixo enviamos um ping para o servidor na internet, porém, nós 
definimos o TTL como 1. 


No. Time Source Destination Protocol Length Info 
1 0.000000 192.168.0.200 37.59.174.232 98 Echo (ping) request 1 


+ Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) 
+ Ethernet II, Src: Vmware 76:43:e1 (00:0c:29:76:43:e1), Dst: ArrisGro 45:c4:0c (d4:ab:82:45:c4:0c) 
+ Internet Protocol Version 4, Src: 192.168.8.288, Dst: 37.59.174.232 q 
0100 .... = Version: 4 
. 0101 = Header Length: 20 bytes (5) 
+ Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) 
Total Length: 84 
Identification: 0xe425 (58405) 
+ Flags: 0x4000, Don't fragment 
Protocol: ICMP (1) 
Header checksum: Oxffef [validation disabled] 
[Header checksum status: Unverified] 
Source: 192.168.0.200 
Destination: 37.59.174.232 


Type: 8 (Echo (ping) request) <—— 
Code: O «—— 

Checksum: 0x9c66 [correct] 

[Checksum Status: Good] 


O comando enviado para o servidor foi o seguinte: 

ping -c 1 -t 1 www.grupobusinesscorp.com (a opção -t 1 define o TTL como 1) 
Enviamos o TTL 1 de propósito justamente para que quando nosso pacote chegar 
no primeiro roteador ele seja descartado e o roteador nos avise que o TTL foi 
atingido. 


Na imagem abaixo podemos ver que o primeiro roteador (192.168.0.1) nos envia um 
ICMP do tipo 11 e código O como esperado. 
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No. Time Source Destination Protocol Length Info 
1 0.000000 192.168.0.200 37.59.174.232 ICMP 98 Echo (ping) request i 
. 002747 192.168.9.1 192.168.0.200 126 Time-to-live exceeded 


Frame 2: 126 bytes on wire (1008 bits), 126 bytes captured (1008 bits) 

Ethernet II, Src: ArrisGro_45:c4:0c (d4:ab:82:45:c4:0c), Dst: Vmware 76:43:e1 (00:0C:29:76:43:e1) 
Internet Protocol Version 4, Src: 192.168.0.1, Dst: 192.168.0.200 

Internet Control Message Protocol 


dá rv 


Type: 11 (Time-to-live exceeded) 
Code: O (Time to live exceeded in transit) <4———— 1º roteador 
Checksum: Oxf4ff [correct] 
[Checksum Status: Good] 
+ Internet Protocol Version 4, Src: 192.168.0.200, Dst: 37.59.174.232 
+ Internet Control Message Protocol 


Vamos enviar um TTL com valor 2, sendo assim nosso pacote passa pelo primeiro 
roteador e será descartado no segundo. 


ping -c 1 -t 2 www.grupobusinesscorp.com (a opção -t 2 define o TTL como 2) 


Vamos ver o resultado 


No. Time Source Destination Protocol Length Info 
3 3.833670 192.168.0.200 37.59.174.232 ICMP 98 Echo (ping) request i 
.844759 10.41.128.1 192.168.0.200 70 Time-to-live exceeded 


5 7.602106 192.168.0.200 37.59.174.232 ICMP 98 Echo (ping) request i 


4 


+ Frame 4: 70 bytes on wire (560 bits), 70 bytes captured (560 bits) 
+ Ethernet II, Src: ArrisGro_45:c4:0c (d4:ab:82:45:c4:0c), Dst: Vmware 76:43:e1 (00:0c:29:76:43:e1) 
Internet Protocol Version 4, Src: 10.41.128.1, Dst: 192.168.0.200 


+ Internet Control Message Protocol 
Type: 11 (Time-to-live exceeded) 
Code: O (Time to live exceeded in transit) 
Checksum: 0x9330 [correct] 
[Checksum Status: Good] 
» Internet Protocol Version 4, Src: 192.168.B.288, Dst: 37.59.174.232 
+ Internet Control Message Protocol 


Conforme esperado o segundo roteador (10.41.128.1) chega ao TTL O então envia o 
ICMP Time Exceeded para nós. 


A grande questáo aqui é que seguindo essa ideia é possível descobrir a rota 
completa do nosso pacote assim como todos os roteadores que a nossa conexáo 
passa. 


Uma forma rápida de tracar a rota usando essa técnica é através do traceroute. 


No exemplo abaixo temos o traceroute trazendo toda rota que nosso pacote está 
fazendo até o destino. 


:% traceroute -n www.grupobusinesscorp.com 
traceroute to www.grupobusinesscorp.com (37.59.174.232), 30 hops max, 60 byte packets 
1 192.168.0.1 2.423 ms 4.115 ms 4.050 ms 
10.41.128.1 25.303 ms 25.180 ms 25.991 ms 
179.212.65.129 25.924 ms 25.838 ms 26.885 ms 
179.212.73.1 26.806 ms 26.728 ms 27.846 ms 
200.178.80.13 29.133 ms 200.247.27.189 27.720 ms 189.86.165.21 29.006 ms 
200.244.216.125 48.617 ms 200.230.158.242 144.846 ms 200.244.211.185 45.525 ms 
200.230.220.62 151.430 ms 134.823 ms 200.230.220.34 129.195 ms 
200.230.252.202 138.538 ms 192.99.146.104 130.027 ms 138.982 ms 
192.99.146.113 166.292 ms 165.265 ms 192.99.146.104 153.679 ms 
198.27.73.202 175.794 ms 198.27.73.218 175.747 ms 170.475 ms 


2 
3 
4 
5 
6 
7 
8 
9 
0 


E 
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Isso só foi possível graças ao protocolo ICMP. 
RECAPITULANDO 


Se você chegou até aqui tenho certeza que tem uma base muito maior sobre como 
uma comunicação funciona, afinal, você foi do zero ao entendimento detalhado de 
cada protocolo de uma forma prática. 


Nós vimos frames, pacotes, segmentos e payloads mas isso é o que nós enxergamos, 
se a gente parar para pensar o que forma tudo isso são bytes trafegando na rede. 


Bytes na rede 


Isso pode até parecer confuso em um primeiro momento, mas não é difícil de 
entender, esses bytes em hexadecimal é o que vai formar a estrutura que estudamos. 


Vamos colorir as informações e destacar o que é mais importante para entender 
melhor 


Frame Ethernet: 
Mac destino, Mac Origem, Protocolo (0800 = IP) 


Pacote IP: 


Versão (4), Header Lenght(5), Tamanho Total, TTL, Protocolo (06 = TCP), IP de 
Origem, IP de destino. 
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Segmento TCP: 
Porta de origem, Porta de destino, FLAGS 


Protocolo HTTP: 
HTTP Request 


Os primeiros 6 bytes são o endereço do MAC address de destino, logo em seguida 
temos o endereço do MAC address de origem e os próximos 2 bytes (08 00) temos o 
protocolo que no caso 08 00 significa protocolo IP. 


Podemos confirmar isso, uma vez que a próxima sequencia de bytes se inicia com 45 
onde o 4 é a primeira informação do header IP indicando a versão do protocolo e 
posteriormente temos o tamanho do header IP indicando 5 que indica 5 sequências 
de 4 bytes (pois cada linha do header IP tem 4 bytes) sendo assim temos 5 * 4 = 20 
bytes de tamanho do header IP. (no nosso exemplo o header IP vai de 45 até e8) 


ga ao eA As ADE 29 76 42 el CE CE 00 
07 00 40 00 


Os próximos bytes que vamos olhar 01 81 indicam o tamanho total do pacote, mas 
essa informação está em hexadecimal. 


Vamos converter para decimal no próprio terminal do Linux 


:% printf sd 0x0181 


4] 


01 81 em hexadecimal é igual a 385 em decimal, ou seja, o pacote tem 385 bytes no 
total. 


Os próximos bytes que vamos olhar é o nono byte do header IP (40) ele indica o TTL 
mas esse valor também está em hexadecimal, vamos converter para decimal para 
descobrir o valor correto. 


0x40 = 64 em decimal, o que pode nos indicar que se trata de um Linux. 


O byte seguinte tem o valor 06 esse byte é o byte que indica o protocolo que o header 
carrega, e 06 é o valor para o protocolo TCP. 


No 13º byte do header IP temos o início do endereço IP de origem MEMES 
seguido do endereço IP de destino AENA porém os valores estão em 
hexadecimal. 


Vamos converte-los 
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printf 'sdin' 0xc0 
192 
printf 'sdin' 0xa8 
168 
printf 'sd'.'sd'.'sd'.'sdin' 0xcO O0xaB 0x00 0xc8 


192.168.0.200 


printf 'sdin' 0x25 
37 

- printf 'sd'.'sd'.'sd'.'sdin' 0x25 0x3b Oxae 0xe8 
37.59.174.232 


Com isso temos como IP de origem 192.168.0.200 e IP de destino 37.59.174.232 
Vamos continuar e colorir o que já vimos até agora 


ab 82 45 c4 Oc 00 Oc el 08 00 45 
81 07 00 40 00 40 06 a8 00 c8 25 
e8 dd 84 00 50 ef 49 96 Ob bd 80 
e5 97 07 00 00 01 01 41 26 5f 09 
94 47 45 54 20 2f 20 50 2f 31 2e 


Nos próximos 2 bytes (dd 84) temos o inicio do protocolo TCP com a porta de origem 
seguido da porta de destino nos bytes (00 50) vamos converter de hex para decimal 
para saber quais sáo as portas. 


# printf 'sdin' 0xdd84 


# printf 'sdin' 0x0050 


Com isso sabemos que a porta de origem é 56708 e a porta de destino é a 80 


Vocé pode olhar a estrutura do header que ensinamos anteriormente para ver a 
posicáo dos bytes certinho, mas com o tempo vocé se acostuma. 


Outro byte importante para olharmos no header TCP é o 14” byte pois ele contém o 
valor das FLAGS TCP. 


No nosso caso o 14º tem o valor de 18 em hex 
ab 82 45 c4 Oc 00 Oc el 08 00 45 


81 07 00 40 00 40 06 a8 00 c8 25 
e8 dd 84 00 50 ef 49 96 Ob bd 80 


e5 97 07 00 00 01 01 41 26 5f 09 
94 47 45 54 20 2f 20 50 2f 31 2e 


Se convertemos o 0x18 de hexadecimal para decimal chegaremos ao valor 24. 


0x18 = 24 em decimal 
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Para entender esse valor precisamos entender como esse valor é calculado, cada 


FLAG TCP tem um valor, conforme podemos ver abaixo: 


URG ACK PSH RST SYN FIN 
32 16 8 4 2 1 


Basicamente quando temos uma flag ativada ela terá um peso para formar esse valor, 
por exemplo: 


URG ACK PSH RST SYN FIN 
32 16 8 4 2 1 


No exemplo acima temos as FLAGS ACK e PSH ativas, se olharmos o peso de cada 
uma dela teremos 16 + 8 que resulta em 24. 


Sendo assim, na nossa análise tivemos o valor 18 em hexadecimal que ao ser 
convertido tem o valor 24 então tudo indica que as flags PSH e ACK estão ativas. 


Logo se temos a flag PSH temos um payload. 
Vamos colorir o header TCP 
ab 82 45 c4 Oc 00 Oc el 08 00 45 


81 07 00 40 00 40 06 a8 00 c8 25 
e8 dd 84 00 50 ef 49 96 Ob bd 80 


e5 97 07 60 600 01 01 41 26 5f 09 
94 47 45 54 20 2f 20 50 2f 31 2e 


Bom, você deve estar me perguntando, como você sabe o tamanho do header 
TCP? 


O byte que antecede o valor das flags 13º byte do header TCP possui o valor 80, 
nesse caso, temos que pegar o primeiro dígito (no caso 8) esse dígito indica q 
quantidade de linhas que o header TCP tem, no nosso caso 8, sabendo que cada 


linha tem 4 bytes podemos fazer 8 * 4 que resulta em 32, sendo assim o tamanho 
desse header TCP é de 32 bytes. (Indo então de dd 84 até 38 94) 


A partir dai temos o payload. (destacado em vermelho) 


Como já estamos a nível de aplicação, vamos converter o hex para ascii e ver o 
início do seu conteúdo. 


47 45 54 20 2f 20 48 54 54 50 2f 31 2e 31 


Podemos olhar uma tabela ascii ou converter usando o echo no Linux. 


-e "Nx47Nx451x54 1 x201x2Tix201x481x541x541x501x2fix31ix2e14xXx31" 


GET / HTTP/1.1 
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Como podemos ver o conteúdo contém um HTTP Request sendo efetuado. 
RECAPITULANDO 


Analisando a seguinte sequência de bytes podemos facilmente chegar a conclusão 
de que o host cliente fez uma requisição HTTP para o host servidor. 


ab 82 45 c4 Oc el 08 00 45 
81 07 00 40 00 a8 00 c8 25 
e8 dd 84 00 50 96 Ob bd 80 


e5 97 07 00 00 41 26 5f 09 
94 47 45 54 20 50 2f 31 2e 


Se colorirmos os bytes podemos ter uma compreensáo maior de cada protocolo 
envolvido. 


ab 82 45 c4 Oc el 08 00 45 
81 07 00 40 00 a8 00 c8 25 
e8 dd 84 00 50 96 Ob bd 80 
e5 97 07 00 00 41 26 5f 09 
94 47 45 54 20 50 2f 31 2e 


Host cliente: 

Mac Address: 00:0c:29:76:43:e1 
IP Address: 192.168.0.200 

Porta: 56708 


Host servidor: 

Mac Address: d4:ab:82:45:c4:@0c 
IP Address: 37.59.174.232 

Porta: 80 


O protocolo de transporte usado foi o TCP com um payload que continha um HTTP 
Request solicitando um recurso na raiz do servidor web. (GET / HTTP/1.1) 


Na imagem abaixo podemos ver o pacote completo 


Ô«. EA... )vCá..E. 
....0.0..dA” .E%; 


.a 2 
8.GET / HTTP/1.1 
«Host: www.grup 


obusinesscorp.co 
m. .User-Agent: M 
ozilla/5.0 (X11; 

Linux x86 64; r 
v:60.0) Gecko/20 
100101 Firefox/6 
0.0..Accept: tex 
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t/html,applicati 
on/xhtml+xml,app 
lication/xml;q=0 
ds /430=0.8..A6 
cept-Language: e 
n-US,en;q=0.5..A 


ccept-Encoding: 
gzip, deflate..D 
NT: 1..Connectio 
n: keep-alive..U 
pgrade-Insecure- 
Requests: 1.... 
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